> Hi Alan
>
> Thanks for your quick response...
>
> Previously in BDE we used to do the same thing, we had this "registry"
> table that used to hold the version number of the data, and like you do,
> every time the application had a newer version the update procedure was
> started...
> But what I want to do there is to improve a little bit of performance,
> for instance if the update flag is up the application has to read all the
> table definitions in the code field by field, index by index and check if
> the current table matches its definitions whereas instead of doing this I
> would like to have a version number for each object. I have hundreds of
> table in the application, in the new version of the application
> if only the
> definition of one table was changed, I'd like to go directly to that table
> and alter it according to the new definition instead of scanning
> all objects
> one by one...
>
> Of course the precaution of being the only user to be connected to the
> database at that time is already taken into consideration
>
> Thanks again
> Vahan
>

but if you version your db on each release, you know exactly which object(s)
need updating. You analyse the diff between the previous release and the
current release and you get an update script. It will therefore only address
the objects which need updating.
Your proposal of analysing the system tables will be far more costly and
also very tricky.
Alan