Search results for query: *

are all the objects in a single MDB, or do you have them split into a front-end, back-end setup?

The .mde's are all on the work stations in the same subdirectory as the dbReference.mdb I mentioned. I have an .mdb on my development machine that I use to develop forms, queries, etc. I compile it to an .mde, and then distribute it to all work stations across the network each night when I have...

I have placed some "reference" type tables, with material that rarely or never changes, in a backend .mdb, and place that in the same sub-directory as the .mde on work stations. That lets the .mde draw the reference data from its local drive, which speeds up the other network traffic.

tested the front-end from the lowest-end machine on the network? have a system in place to deliver new front-ends to work stations when you've made updates? tested it while logged in as a test user with the lowest security levels that you use? we also work in an NT environment, and these...

You might achieve some performance increase by storing the front ends on the local machines along with any reference files that application might use that would not be subject to frequent change. Reducing the amount of network traffic normally is a bonus.

except for rosters, schedules, and maybe minutes and shots on goal i can't think of anything to track in soccer. few statistics. you might consider a sheet-music cataloging system. a number of publishing items could be captured about the material along with technical notes and categorized...

total of all files right now is about 650mb in a couple of dozen back-end files. largest single file is about 165mb. front-end is currently about 12mb, but is soon to expand.

DoCmd.RunMacro "macName"

What version of Access are you using?

I've only done this in NT4, but there is a way to grab the user's network login ID and use it within your application for security, file and function access, event tracking, and other purposes. That saves the end users from logging in twice, but still captures some useful security data...

What function is performed by the "OpenStartup" that's called at the end?

Do you plan to have the data files on the CD, or just the front end?

Like most, we have a number of tables with "live" data that gets constantly modified, and new records added. There are also tables with data that rarely or never changes (Zip codes, state abbreviations, violation codes, district designators, etc.), which we call reference data. I've...

I apparently got a hiccup in the first download. DL'd the file again. This time it was 470 *bytes* longer, and installed like a champ. I am still moderately confused, however. I find no access to a data base module. Adabas is installed, and the SO6 installation detected it. It opens and uses...

When I try to install the download, I get the brief flash of a DOS window, and then nothing. The Player installs, though I don't know if it works properly as there were no play-able files with it. Adabas seems to install, but will not run on its own. The 95mb dl is the one that will not run.

Can't get it to install or run on my Win2K machine.

Depends largely on the format in which the data is stored. Many DOS programs stored data in dBase compatible forms. That's one that Access can easily read and import. Remember that you're not importing the application or the program, just the data files.

An odd follow up: when I drop the Row Source information from the combo box, and turn it into a simple text box - the dlookup code works! Since the combo box would not display any numbers higher than 65537 when it was tied to the table, it follows, I suppose, that the dlookup had no number to...

...as completely normalizing the tables, the reason for the lookup is to keep a history of addresses. These people move, and some of the users want that history, not just the current addresses. Does the fact that the combo box displays *part* of record 65537 tell me anything? Thanks again. -Terry

I'm familiar with SQL, but am lousy at using it. I use dlookup because it seemed a quick and simple way to grab data from one file, and use it in another. A left over from my days of writing DOS applications using dBase, I suppose. In this case the data entry people will always have the record...