Do I really want to split my DB?

[michelleb1]

The db will have about ten users. I am doing this in stages, so I will definitely be adding & modifying forms and reports. If I don't split - I can just import the new forms and reports into the db on the network. If I do split it, then I'll have to import them from each of the user's machines right? Not splitting seems easier since as of right now I don't necessarily need to split it for any particular reason. The users do not need to design their own forms, queries, or reports, And I haven't yet tested it on the network and have no idea how fast or slow it will run. I don't know if there is a right or wrong answer but I would appreciate your opinions. Also, is it recommended that I import forms and reports rather than copying and pasting?

Thanks So Much! and I appreciate all the help I've gotten thus far,

Michelle

 

[ajdesalvo]

If you split it and all shared data is on the network, then all the users would need to do is copy your latest version to their workstations. If they all link to the same path (ie., F:\Access\Path), then this is really easy.

A simple way to get everyone updated would be to place the new version in a directory on the server, then email everyone to get the latest version.

Another way would be to create a .bat file that has a simple copy command. Then create a desktop icon that the users can click on to get the latest version. Anthony J. DeSalvo
President - ScottTech Software
"Integrating Technology with Business"

 

[KornGeek]

I recommend splitting your database. This allows you to keep the data separate from the forms. You can completely do away with importing the new forms. You simply use the updated front-end, and the data remains constant.

Also, (and this is strictly my opinion) I feel that when dealing with a multi-user database, it is much cleaner to use separate copies of the front-end on each user's local machine, and a shared back-end on the network. I have heard of some speed issues with leaving a shared front-end on the network, but I don't know if that would necessarily become an issue for you.

That's just my 2 cents. Good luck with whatever decision you make.

 

[annsolomon]

If your users share one copy of the database on the server they'll be tripping all over each other. MUCH better to put a copy of the front end (forms, queries, reports, etc.) on each individual's PC as has already been suggested here. I usually direct my users to place their copy of the FE in a specific location on their PC and then place an icon on their desktop that includes the location of their Microsoft application and the FE database in the Target field. (I also put the workgroup information file in the Target field so they automatically join and exit the WIF when using one of my applications.)

A note about copying and pasting -- use with caution. There are some known issues that MS hasn't completely fixed yet. If you do copy/paste, be sure to compile the code prior to saving the pasted object and you'll probably be okay. Ann

 

[michelleb1]

Is it true that Filter by Form cannot be used to search if you select from a combo-box? I read that in someone's post. I split my db and tried it - everything seemed fine - am I missing something - I really need users to be able to use that feature to search.

 

[BSman]

First, absolutely split the database so the tables (except for any appropriate application control tables) are in the "back end" (data) and everything else is in the front end (application). Just link to the back end (data) tables. It's much, much easier to just copy the new front end over the old front end. Copying reports, etc., into a single database is asking for problems and makes it difficult to compact the application part to minimize its size.

ALL of my applications (and I have many in use) are split. It turns a support/upgrade/maintenance nightmare (with one database) into a much easier job and also means almost no down time to the users. If the users are running off copies of the application on their workstations, it means basically no down time for the users.

As far as keeping it current, try doing this:

Set up a table (in the back end) called "Version" with two columns, VersionNumber and VersionDate.

Set up the same table, but named "LocalVersion" in the application.

Both of these tables will only have one record.

When you create and distribute (on the server) a new version, be sure that the new version contains the appropriate data in LocalVersion and that you copy the same data to the Version table.

Include in your application code that when it's started the contents of LocalVersion and Version are compared, and if they don't match tell the user to upgrade (copy from the server). If you want you could force log out the user or let the user continue using the old one if you want.