I am developing a system which will be delivered as a run-time product where the early months of live operation are likely to see the need to revise and add to the repertoire of text generation functions. Wherever possible I've tried to use table data ( queries ) but there are many cases where program code is required. (If Access had stored procedures then this would probably solve my problem.)

My plan was to move all these functions into a library db just containing code modules. I planned to re-issue just the library database if function logic needed to change or additional functions where needed. I realised that problems would arise if any functions used by the the main db were removed but I didn't ( perhaps foolishly !) think there would be any issues if the statements inside a function were amended.

It now appears that any changes made to the library db cause a run-time error. The runtime application certainly uses the library db - if it isn't there then it gives and error. My experiments suggest that any change to the library db will cause an error - it looks as though there is something in the compiled main db which is able to detect if the libary db isn't exactly the same as the db which was used in the compilation/assembly.

Am I right that my original assumption was wrong - you can't change a library db in a run-time application ? And if I am, can anyone suggest a solution to my problem which will allow data manipulation changes to be made without requiring the re-installation of the application ?

Thanks

Peter

Thanks - will look up the url you give.

I tried the .dll and it fails with the same problem as the library db. My test was as follows.

I built a .dll in VB6 - it self registers on the pc where it is created. I then created an .accde and included this dll as a reference. I then altered one of the functions in the dll and re-compiled it. The new version of the .dll is implemented without problem on the .accdb ( presumably automatically re-compiled ) but the .accde fails. Presumably the Access db holds some id related to the reference so it knows if it has changed. Clever stuff.

Interestingly a run-time application built using a version of an office product as a reference will run without any issues if installed on a pc with a higher version - e.g an application built using Word 2003 runs without hitch if insalled on a pc with Word 2007 or 2010. So maybe there is some intelligence in the code which decides whether or not to flag an error. Maybe it knows that later office versions only differ from earlier versions by the addition of properties and methods - past objects will remain unchanged. But in a custom .dll it has no means of knowing.

Thanks

Peter