Firstly don't pay much regard to those points. Anyone who has answered questions here for a while will soon build up points provided their answers aren't totally stupid. Personally I don't like them, and would prefer to be judged by others
solely on the quality of my responses. I fought a prolonged and partially successful battle with Microsoft some years ago to stop them sticking letters after my name in forums.
If you have to make extensive changes to the back end then it is probably best to get the end user to send you a copy of it and for you to make the changes to that and return it to them. This of course has implications:
1. The end user will have to pause any data input until you give them the new front end. Or….
2. They can continue to input data, but you'll need to provide them with the means to transfer the data into an empty new front, e.g. by including the necessary 'append' queries in the new back end file and a simple interface for them to be able to browse
to, and link to the old back end, and then execute the queries in the correct order so that referential integrity is not violated. Or….
3. Instead of sending them a new back end, send them a file in which a reference to the existing back end is returned by browsing to it, and then executing routines which execute the necessary CREATE, DROP or ALTER TABLE statements to update the
old back end. It might also be necessary to move data around once the table definitions have been amended.
Over the years I've done all three of the above, depending on the context in which the back end is being changed.
Whatever you do, I really can't emphasise too much how unwise it would be to stick with the present set-up where the three users are accessing the same single file. Sooner or later the brown stuff will make contact with impeller.
Ken Sheridan, Stafford, England
