|Subject||Re: Was: Guid Support|
> How are you going to assign the database identifier? We do aEach database has an id which is needed for the incremental data
> thing in one of our systems. The primary key is made up of a 3 char
> database prefix, 2 chars for the table and 10 chars for a unique
> number (from a generator). This gives us a char(15) key.
transfer (transport changes into the central database).
When setting this id wrong, the data transfer won't work,
so they are forced to set it correct.
Additionally, we have a table of all ids in our application hardcoded
to check them. This requires a new app when adding a database, but
saves a lot of support time.
> Also a guid can I believe be stored as a char(8) which is smaller.I do not know any algorithm which does this.
> You seem to be making a very complex system for key generation whenI am not sure if GUID is unique for us, since some customer use
> guids (or uuids) are available in most operating systems and many
> databases (MSSQL server, Oracle etc).
> Having tried both approaches, I would use a guid. These can also be
> generated in the application rather than the database if desired,
> requiring no access to the database (unlike your method which
> requires the high id to be generated via the database).
Microsoft Terminal Server which would result in the same MAC-adress
for severall clients. With our approach I can handle this situation.
The high id is stored in a table and is read and incremented with the
old value in the where-clause. When no row has been updated, another
user did an update at the same time and I have to start it over.
I tried to shrink the needed bits and would need at the moment
64 bits. Fortunately, interbase supports this via INT64 and NUMERIC
(18,0). Numeric is portable, so I could use this key also on other
databases like Oracle.
Unfortunately, the BDE doesn't support large ints (or I am to stupid
to get it working)!!!! Does anyone know how to get this working?
Thanks in advance,