hi,
i do understand when you say that PRIMARY KEY "can" have
a.) more that 1 x FIELD
b.) other than Type SERIAL
but it is not the Situation i talk about
---
i talk about User which want to "upgrade" from DBF to SQL and use Postgre and have no Idea how
a.) xBase have RecNo() which SQL does not have so we need a "Replacement" under SQL
there are "other" User which already have a working Concept like Xbase++ PgDBE which have some "internal" FIELD
so i do "add" some "internal" FIELD when "import" DBF to PostgreSQL Table lile "__record" or "__deleted"
- Code: Select all Expand view RUN
cQuery += " __deleted boolean NOT NULL DEFAULT false, "
cQuery += " __record serial NOT NULL, "
other like "__rowversion" or "__keyversion" are use by Xbase++ ISAM-Emulation with need some TRIGGER
- Code: Select all Expand view RUN
cQuery += " __rowversion integer NOT NULL DEFAULT 0, "
cQuery += " __keyversion integer NOT NULL DEFAULT 0, "
cQuery += " __lock_owner integer NOT NULL DEFAULT 0, "
also PRIMARY KEY is "add" when create SQL-Table to use NextVal() "internal" to increment UNIQUE "RecNo"
---
1st. "Problem" for a xBase User are FWPG_ImportFromDBF() which use 4th Parameter as "default"
it should "add" those "missing" FIELDs when FWPG_CreateTableSQL()
it does not hurt User but help "internal" to "add" some FIELDs
btw. Alaska "add" many "internal" FIELDs for PgDBE ISAM Emulation.
---
Fivewin should have a "minimum" of "equivalent" to make it easy to change from Xbase++ to Fivewin
a Reason for Xbase++ User can be, when using PostgreSQL, that they have "big" Data > 2 ^ 32
Xbase++ are only 32 Bit and UNICODE is not realty supported ...
so i think of xBase User which want to "upgrade" there *.DBF, not of User which work with PostgreSQL and "downgrade" to ISAM Style
please keep it in Mind when work on new CODE for PostgreSQL to use under Fivewin, thx