Delphi 2007, NOT using unicode stuff.
I am in process of upgrading from ElevateDB 2.01x to 2.03x. When I upgraded from version 1.9x to 2.x, I ran into Error #100 (or something similar) due
to "version mismatch" that gave me a lot of grief due to mismatched metadata that I did not understand at the time (still don't on most days).

There is a command, my guess, something like: "Update Database" or "Upgrade Database"  to update metadata when ElevatedDB version changes (not
sure one word or two words; could be something entirely different, so please don't be misled by my guess). I spent a few hours on Newsgroups today but
can't find the command or the syntax.

Will someone be kind enough to remind me of *** exact command and proper syntax to use it? *** (This time, I am going to post it on wall .

Thanks

JayM

<< Jay M wrote:

Delphi 2007, NOT using unicode stuff.
I am in process of upgrading from ElevateDB 2.01x to 2.03x. When I upgraded from version 1.9x to 2.x, I ran into Error #100 (or something similar) due
to "version mismatch" that gave me a lot of grief due to mismatched metadata that I did not understand at the time (still don't on most days).

There is a command, my guess, something like: "Update Database" or "Upgrade Database"  to update metadata when ElevatedDB version changes (not
sure one word or two words; could be something entirely different, so please don't be misled by my guess). I spent a few hours on Newsgroups today but
can't find the command or the syntax.

Will someone be kind enough to remind me of *** exact command and proper syntax to use it? *** (This time, I am going to post it on wall .

Thanks

JayM
---------------------------------- >>
My upgrade from EDB 2.01 to EDB 2.03 build 6 went fine. I did not have to update/upgrade Catalog/Database manually.

I don't know if this was not needed in the first place (though Catalog table's  structure DID change per Tim), *** OR *** EDB is smart enough to take care
of the issue in background. In either case, I am happy as long as I can move forward with programming.

JayM

Jay,

<< I don't know if this was not needed in the first place (though Catalog
table's  structure DID change per Tim), *** OR *** EDB is smart enough to
take care of the issue in background. In either case, I am happy as long as
I can move forward with programming. >>

The way that it works is this:

New minor releases will often have config/catalog file changes, but these
changes only take place the next time that the config/catalog is updated
using the newer minor release, and such changes are transparent.

After a config/catalog is updated using a newer minor release, then it is
not accessible using the older version of ElevateDB.  Any attempts to do so
will result in an error about the version being incorrect.

Newer minor releases can *always* read older config/catalog files.

As an aside, the next 2.04 release of ElevateDB will have two additional
features:

1) The ability to see the version of any given catalog.  This is useful for
determining if a catalog has been updated yet or not by the current, newer
version of ElevateDB.

2) The versioning between table files and the catalog metadata for a table
will work on the basis of a matching structure.  That is, if you have a
catalog file that matches a set of table files currently, and then save it
somewhere else (like in a backup), alter the table to add a column, alter
the table to drop the same column, and then restore the original catalog
file, the table files will still be usuable with the old catalog.
Currently, this is not the case, and attempting to do so will result in an
error about a version mismatch between the catalog and the table files.

--
Tim Young
Elevate Software
www.elevatesoft.com

<< "Tim Young [Elevate Software]" wrote:

Jay,

<< I don't know if this was not needed in the first place (though Catalog
table's  structure DID change per Tim), *** OR *** EDB is smart enough to
take care of the issue in background. In either case, I am happy as long as
I can move forward with programming. >>

The way that it works is this:

New minor releases will often have config/catalog file changes, but these
changes only take place the next time that the config/catalog is updated
using the newer minor release, and such changes are transparent.

After a config/catalog is updated using a newer minor release, then it is
not accessible using the older version of ElevateDB.  Any attempts to do so
will result in an error about the version being incorrect.

Newer minor releases can *always* read older config/catalog files.

As an aside, the next 2.04 release of ElevateDB will have two additional
features:

1) The ability to see the version of any given catalog.  This is useful for
determining if a catalog has been updated yet or not by the current, newer
version of ElevateDB.

2) The versioning between table files and the catalog metadata for a table
will work on the basis of a matching structure.  That is, if you have a
catalog file that matches a set of table files currently, and then save it
somewhere else (like in a backup), alter the table to add a column, alter
the table to drop the same column, and then restore the original catalog
file, the table files will still be usuable with the old catalog.
Currently, this is not the case, and attempting to do so will result in an
error about a version mismatch between the catalog and the table files.

--
Tim Young
Elevate Software
www.elevatesoft.com
--------------------------------------------------->>

Tim,

Thank you for your the explanation as well as for upcoming features you noted - both very useful.

While on the subject, let me add to "Wish list" - I am sure you like that

1. How about providing some means to [re]set version all or selected tables? As you know, during development, table structure gets changed numerous
times, no matter how well you plan ahead. So, when App is done and I want to send app out with Empty Tables, I should be able to set [selected/all]
table's version to whatever, e.g., something to match App version.

Unless already somewhere and I don't know about it, this could eventually be in EDBMgr app. Since EDBMrg is changing table version centrally, it will make
sure that entries in Catalog and Table header remain synchronized.

2. When you have free time we need a "Newbie Level" write-up on Catalog - its purpose, what it does, dos and Don'ts, etc. Hopefully, this will save
you time in the long run as there is lot of discussion on NG because of EDB users' poor understanding of this subject.

3. Aside: When you "Empty Table" - does this reset the Autoinc to seed value? If not, how can we do this so that developer's can empty tables which
contain test data used during development and supply these empty tables with App. (This also goes back to #1 - reset version number at this point.)

And: THANK YOU for abililty to rename objects and Copy Table feature in EDBMgr - what a great time saver these are. (Now I am going to complain about:
Why did you not do this sooner...

JayM

Tim

>2) The versioning between table files and the catalog metadata for a table
>will work on the basis of a matching structure. That is, if you have a
>catalog file that matches a set of table files currently, and then save it
>somewhere else (like in a backup), alter the table to add a column, alter
>the table to drop the same column, and then restore the original catalog
>file, the table files will still be usuable with the old catalog.


Hurrah

Roy Lambert

Jay



>1. How about providing some means to [re]set version all or selected tables? As you know, during development, table structure gets changed numerous
>times, no matter how well you plan ahead. So, when App is done and I want to send app out with Empty Tables, I should be able to set [selected/all]
>table's version to whatever, e.g., something to match App version.

If you send out the catalog then you're stuck with the version in the catalog, if you send out the sql code (obtained via reverse engineering)  and create the catalog/tables on the fly you can set the version number to whatever you want.

Roy Lambert [Team Elevate]

<< Roy Lambert wrote:

...

If you send out the catalog then you're stuck with the version in the catalog, if you send out the sql code (obtained via reverse engineering)  and create the
catalog/tables on the fly you can set the version number to whatever you want.

Roy Lambert [Team Elevate] ----------------------  >>

I knew about and have used reverse-engineer feature for table but apparently missed the fact that one can do the same for Database. More importantly,
missed the fact that running the reverse-engineer generated script will create not only the tables in the database but also its Catalog.

Thank you for pointing out - I missed the [not so] obvious.

Jay

Jay,

<< 1. How about providing some means to [re]set version all or selected
tables? As you know, during development, table structure gets changed
numerous times, no matter how well you plan ahead. So, when App is done and
I want to send app out with Empty Tables, I should be able to set
[selected/all] table's version to whatever, e.g., something to match App
version. >>

You can do this already with the user-defined version number for a table.
This will be expanded shortly to procedures, functions, and views also.  For
more information, see the CREATE TABLE statement:

http://www.elevatesoft.com/manual?action=mantopic&id=edb2sql&category=10&topic=163

specifically the VERSION clause.  The same syntax works for ALTER TABLE, so
you could just use:

ALTER TABLE MyTable VERSION 1.00

on every table in the database.  This is a stored procedure that will do it:

CREATE PROCEDURE "ResetTableVersions" (IN "NewVersion" DECIMAL(19,2))
BEGIN

  DECLARE CatalogCursor CURSOR FOR CatalogStmt;
  DECLARE TableName VARCHAR DEFAULT '';

  PREPARE CatalogStmt FROM 'SELECT * FROM Information.Tables';
  OPEN CatalogCursor;

  FETCH FIRST FROM CatalogCursor (Name) INTO TableName;

  WHILE (NOT EOF(CatalogCursor)) DO

     EXECUTE IMMEDIATE 'ALTER TABLE '+QUOTEDSTR(TableName,'"')+' VERSION '+
                       CAST(NewVersion AS VARCHAR);

     FETCH NEXT FROM CatalogCursor (Name) INTO TableName;

  END WHILE;

END

<< Unless already somewhere and I don't know about it, this could
eventually be in EDBMgr app. Since EDBMrg is changing table version
centrally, it will make sure that entries in Catalog and Table header remain
synchronized. >>

You're getting the two different types of "versions" confused.  There is the
internal version number used by EDB for making sure that any table file
matches the database catalog, and there is the user-defined version number
used by you for determining which catalog object is at which version in
terms of your database schema.  Think of the internal version number as a
checksum that represents the current table structure, and something should
never be reset or modified by anything other than EDB.

<< 2. When you have free time we need a "Newbie Level" write-up on
Catalog - its purpose, what it does, dos and Don'ts, etc. Hopefully, this
will save you time in the long run as there is lot of discussion on NG
because of EDB users' poor understanding of this subject. >>

Sure, I'll see about getting a technical article up about this.

<< 3. Aside: When you "Empty Table" - does this reset the Autoinc to seed
value? If not, how can we do this so that developer's can empty tables which
contain test data used during development and supply these empty tables with
App. (This also goes back to #1 - reset version number at this point.) >>

You don't need to supply empty tables with an application.   Just provide
the database catalog (edbdatabase.edbcat) in the database directory, and EDB
will automatically create the appropriate table files the first time the
table(s) are opened.

<< And: THANK YOU for abililty to rename objects and Copy Table feature in
EDBMgr - what a great time saver these are. (Now I am going to complain
about:  Why did you not do this sooner... >>

There is a lot of dependency between objects in the EDB catalog, and so it
is a little difficult to just go around renaming things.  Plus, renaming is
not actually in the SQL standard.  The copying functionality has basically
been around since the beginning in the form of:

CREATE TABLE MyTable
(LIKE MyOtherTable)

INSERT INTO MyTable SELECT * FROM MyOtherTable

But, the EDB Manager does it a little differently, and just simply copies
the metadata and creates a brand new table from it using its SQL generation
functionality.

--
Tim Young
Elevate Software
www.elevatesoft.com

Roy,

<< Hurrah >>

Yeah, I thought you'd like that.  More proof that I keep everything, and
you'll never know when a request of yours will show up.

--
Tim Young
Elevate Software
www.elevatesoft.com