METHOD SavePQQ() need "id" or how to use own PRIMARY KEY ?

[Jimmy]

hi,

using c:\fwh\samples\testpgre.prg i can open Table "CUSTOMER"
it work fine when "edit" but when try to APPEND it does crash

it have to do with

9.15. Sequence Manipulation Functions

Sequence Functions like currval(), nextval() or even lastval() need Type SERIAL
so Table should create with

Code: Select all  Expand view

  cQuery += " CONSTRAINT " + xTable + "_pkey PRIMARY KEY ( ´serial´ )"

---

i wonder how to "identify" a Record without UNIQUE "id"

in multi-User Environment 2 User can APPEND "same" at "same Time" so i can´t use Information like "First+Last" as "Key"
you need a PRIMARY KEY Type SERIAL where nextVal() ( NOT currval() ) is used when INSERT new Record

btw.
how can i make FIELD "id" as READ-ONLY when "edit"

[Jimmy]

hi,

Another issue:
The function FWPG_PrimaryKeys() is always returning zero rows.

better is IMHO to use function GetSerialC()

Code: Select all  Expand view

...  " and column_default like 'nextval(%'"

[nageswaragunupudi]

hi,

Another issue:
The function FWPG_PrimaryKeys() is always returning zero rows.

better is IMHO to use function GetSerialC()

Code: Select all  Expand view

...  " and column_default like 'nextval(%'"

No
Anyway, this is fixed now. We will share the modified sources with you soon, after I finish some other issues and testing.

[nageswaragunupudi]

in multi-User Environment 2 User can APPEND "same" at "same Time" so i can´t use Information like "First+Last" as "Key"
you need a PRIMARY KEY Type SERIAL where nextVal() ( NOT currval() ) is used when INSERT new Record

As I said in my earlier post, it is always good to have a SERIAL primary key. RDMS will take care of nextval() or currval() and it is not other botheration. RDMS will safely append even hundreds of records per second.
No worries.

i wonder how to "identify" a Record without UNIQUE "id"

We need to have a primary key or unique key (key can have multiple columns also)

btw.
how can i make FIELD "id" as READ-ONLY when "edit"

You do not have to do anything.
Auto-increment fields are always treated as ReadOnly both by XBrowse and DataRow.

[nageswaragunupudi]

using c:\fwh\samples\testpgre.prg i can open Table "CUSTOMER"
it work fine when "edit" but when try to APPEND it does crash
Image
it have to do with

We will get back soon with a solution

[nageswaragunupudi]

using c:\fwh\samples\testpgre.prg i can open Table "CUSTOMER"
it work fine when "edit" but when try to APPEND it does crash
Image
it have to do with

We will get back soon with a solution

Fixed.
Please wait a little and we will send you the modified "pgsuport.prg"

[Jimmy]

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

     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

     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