Access Object / VBA Compare Utilities

[jmcclain]

I've created an Access database for a client. The database is the property of the client, so I'm not going to 'lock' the code down, but I'm concerned that they are going to make some changes to the database and then expect me to continue to support the database. Of course I have set the expectation that once its changed, I'm not going to support it (unless I get more $$), but they may deny making any changes.

Have any of you used a utility such as AccessDetective for this purpose?

I'm trying to avoid having to export the VBA out of both databases (original and modified) and using MS Word to do a comparison of the code, as that can be painful and time consuming. This would identify VBA changes, but not changes to form controls or the database schema.

Any ideas on utilities to use or other ideas would be greatly appreciated.

Thanks!

Jason

 

[vbajock]

You could export the code to a text file and then pull it back into a table, add a counter field and a date field and number the lines and date stamp each record.
The next time you are there, if you suspect a code change, do the same thing and run a join query by joining the number and text fields on the original and the existing. If someone has changed it you will have the original and the new to prove it.

 

[MichaelRed]

Every "SQL" dtabase (according to the standards) is "self documenting". In Ms. A. this is available through a number of avenues. Assuming you are not doing anything too far from the beaten path, a convenient and (so far) ahndy reference is simply the MSysObject table. It lists all objects within an .MDB. the creation and modification dates, along with other interestin arcania. A simple copy of the table should be sufficient for the identification of which objects have changed. Additionally, under the tools menu is the dbdocumenter, which can be used to rather exhaustivly list the various objects along with their various attributes. Various others have mentioned that the documenter can be configured to oupput to tables, so given the you could identify the object and have sufficient paper (or disc space) for the documenter, identifying changes at some level of detail should be quite possible.

Having meandered through all of that, I would probably not do it. At best, I MIGHT consider a (brief) acceptance test based on written and QUITE specific requirements documentation and perhaps even a small 'warranty' period - where you agree to maintain a COPY of the app and fix any bugs they find ON THE COPY and re-install (or update) the app. If they find a problem, one PRESUMES that it is either reproduceable on YOUR copy - or occurs due to changes. If the former, you SHOULD fix it, if the latter, it become the "for Fee" situation.

I would also make this clear in any agreement (legally). Of course, there CAN be some issues which are not necessarily re-produceable in Your environment, but which occur in the production environment. Ther should be very few of these (from a well designed and implemented app), but they CAN occur. If the 'buyer' insist that it is 'one of those', just START with a re-install. If they 'balk' it isn't your problem. If this is acceptable, then DO IT and then let them demo the problem to you.




MichaelRed
m.red@att.net

Searching for employment in all the wrong places