Front end / back end question

[gusbrunston]

Hi.

It was my impression that splitting the database would be best for performance--the tables of data in the back end. I recently saw a suggestion that queries and perhaps modules should be there as well. I'd appreciate your informed comments. Gus Brunston An old PICKer, using Access2000. I manage

http://www.rentdex.com.

Suggestions welcome. padregus@attbi.com

 

[jimmythegeek]

Splitting a database does not usually increase performance. In fact, depending on where the back end is, it can slow performance (across a network, I have way too much experience with this!).

The main benefit to splitting is that you can modify the front end all you want, and never affect the data.

I would not put anything but tables in the back end, but that's me. I don't know how your performance could be better running a "Linked" module or query over a "Local" object. Jim Lunde
compugeeks@hotmail.com
We all agree your theory is crazy, but is it crazy enough?

 

[gusbrunston]

Thanks, Jim.

I did split the database to run it over a network, and so that I could work on the front end without disturbing what was going on.

I can't see any advantage to having anything but the tables in the back end, either. Thanks again. (I see lots of posts about your calendar.)

Cheers. Gus Brunston An old PICKer, using Access2000. I manage

http://www.rentdex.com.

Suggestions welcome. padregus@attbi.com

 

[calian]

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.

 

[jimmythegeek]

Calian,

Is everyone running the same .mde from the network. If so, it would be faster to have the .mde on each workstation, that way the only thing coming across the network is the data. If they all run it from the network, I guarantee it will be slower (I've done it both ways many times).

The disadvantage to that way is that when you make a change to the .mde, you have to get it out to the workstations. I have set up a batch file that runs in the user's login, that copies the latest version of the .mde down to their hardrive, and I never have to worry whether they have the latest copy or not.

This way, only the backend is on the network. So the workstations don't have to pull down all the other objects from the .mde as well (forms, reports, modules, etc), thus minimizing network traffic.

Let me say however, that I currently do it both ways, and sometimes you gotta to what ya gotto do. I do believe thought, that this option (local - network) is the most efficient way if it is possible. Jim Lunde
compugeeks@hotmail.com
We all agree your theory is crazy, but is it crazy enough?

 

[rjr]

I am new to Access and the database I have installed is split as all of you describe. Meanwhile, I am using the Switchboard Manager to help me with the "menu" aspects, and I am not quite sure how to do the updates given it creates a table. I suspect it may have something to do with how I link tables from frontend.mdb.

Right now all tables are in backend.mdb, and all table links in frontend.mdb are to backend.mdb. I use a batch file to update the client's frontend.mdb. How can I incorporate changes to the Switchboard table in the update? Thanks for the help. Hope I am not too far out of the thread subject.

 

[calian]

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 made useful revisions. In our situation, I'd rather "push" distribute it than have the latest version automatically copy at logon time. We have a lot of sohrt term use - guys who come in from the field, log on, work about 10 minutes, and then gone again.

 

[jimmythegeek]

rjr,

The switchboard table should be in the front end. This needs to change with the front end changes. Jim Lunde
compugeeks@hotmail.com
We all agree your theory is crazy, but is it crazy enough?