Developer best practices (1 Viewer)

[battenberg]

HELP....developer best practices

Hi and thanks for all the help so far.....

When it comes to developing Access, what is the best practice given this scenario.

The database I am developing will be multi user, I have created the table structure and a few forms to input the data into. My boss wants the database populated with the back catalogue paperwork data from the filing cabinets.

Is it advisable to be developing a database while someone else is populating it? this is a hyperthetical question at this stage....

What is the best practice?

thanks

 

[ColinEssex]

Personally, I never let anyone use a database I am developing.

If things are that urgent, your boss should have thought of it before to allow you time to get it done properly.

Col

 

[jesusoneez]

As long as the table structure is 100% finished, there should be no problems with users entering data. If on the other hand, there are likely to be table structure changes, I'd strongly recommend waiting until tables are 100% before entering any live data.

Although Colin is right, in some cases it's not practical, and I rarely finish a database that isn't in use to some extent. However, in your situation, I'd use replication quite a lot. As you've said, you have given them some forms for data entry. You should have a design master to work on. Any changes you make can be tested and replicated to the user database(s).

 

[battenberg]

Thanks for the tips, can anyone give me a quick dummy's guide to replication please???

Thanks

 

[Pat Hartman]

Replication isn't necessary. What you need to do is to split the database into a front end that includes all the forms/reports/queries/macros/modules and a back end database that includes ONLY tables. The splitter wizard will do this for you. This allows the users to have copies of your front end while you are still building objects. Their fe's are linked to the shared be on the server. Once you have changes to the fe that you want to push out to them, simply replace their front end databases. The data is still intact in the shared be and you don't have to worry about importing it unless you have made table design changes.

Access 2K and newer will not allow multiple users when someone is making design changes unless you install SourceSafe. Be VERRRRY careful about making a design change in a database that has been opened by someone else, Access may just discard your design changes SILENTLY and you'll not know it until the next time you try to use the database.

And finally, it is simply poor practice to be modifying objects on the fly while users are imputting production data. You are putting the data at great risk of corruption.

 

[battenberg]

Mmmn...this fell over today....

I used replication, to create the database for the user input. Then I made some design changes and the replication failed !

at such an early stage of development this is not such an issue, but in the long run it could be a problem if the tables became too populated....

 

[Pat Hartman]

Replication only replicates data. It does not replicate objects. That is why you need the split database. It allows you to replace objects without disturbing data.

 

[battenberg]

I now find myself working on a replica database, I dont know how it happened but it did, How do i change it to the design master? the 'Recover Design Master' is greyed out!

feel free to use the words 'You Muppet' in any response!!!

 

[Pat Hartman]

It does make you feel dumb doesn't it? Having done equally muppetish things, you have my sympathy. Search the MSFT kb and MSDN library. There should be a FAQ there that covers the problem. If you decide to futz with security, be sure you make a couple of backups

Here's a start:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnacc2k/html/dbrepjet.asp

 

[jesusoneez]

Can't say I've had the problem before! As Pat has said, splitting the database into backend and frontend systems is a good idea. The way I usually work is to get my tables to 100% percent (I usually make management agree and sign something, so that I can blame them if I argue about later changes they decide they want).

Once I have my tables (backend database), I create a Design Master for my frontend forms/queries/reports. Once new items have been tested, I replicate them to the er...replicants. I usually have a pretty complete frontend before I let the users loose on it, and only minor changes are replicated whilst live...bug fixes, tab orders I've missed, that kind of thing.

Never had a problem with corruption doing it this way (Access 2003).

EDIT: I DO make sure all users are out of the database before doing a replication. This is easy for me as I'm only talking about four or five users, but if you're talking about 30+ and multi-sites then it's more difficult to police. Some way of scheduling replication to 23:00 would be nice...hmmm....