"Michael Culley" <mike@vbdotcom.com> wrote:
>Kleanthis,
>
>regarding the answers from doug and paul, IMO, stick with the ALTER TABLE
>statement. ADOX is bugger and if you do use it, make sure you get what you
>wanted (there was a bug that cause some fields that were set required to
>show up in access as required but not actually work as required)
>
>We do this quite a bit here and have a simple method that enables us to
>modify the database freely. We store a value somewhere in the database which
>indicated the version number. If this number is 1 (or not found) we call

the
>routine to upgrade to version 2. This routine will make the required changes
>to the fields. If there are any other upgrades then these are run also eg:
>
>If GetDBVersion=1 Then RunUpgrade1to2
>If GetDBVersion=2 Then RunUpgrade2to3
>If GetDBVersion=3 Then RunUpgrade3to4
>etc
>
>This way we can open any version of the database in the latest build of

the
>app.
>
>Once the upgrade is done we drop all queries and create them again (we also
>do stored procs, indexes, foreign keys, defaults, triggers and constraints
>in SQL server).
>
>This also means that any import routines (from the old dos version of our
>apps) do not have to be changed to accommodate the new database, they just
>import a version 1 db and then the upgrade is run.
>
>--
>Michael Culley
>www.vbdotcom.com
>
>