I'm trying to append/insert records with an Identiy field (as primary key)
with TTable. But Delphi(4) doesn't recognize this field as an Auto
Increament field. I even tried to append records with the SQL Explorer, but
it didnt work.
I think that the problem is that the BDE doesn't recognize this field as an
AutoIncreasment and therefore doesnt allow me to append record without
giving this field a value, and if i give this field a value the sql server
araise execption for trying to set a value to an Auto Increasment field.
i tried to use the AfterPost and AfterInsert Event in order to reset this
field value but it didnt work.

Does anybody knowns what the problems is, and how can i append records that
contains identity fields that cannot be null with a TTable?

Try setting Required property of coresponding TField(s) to false. This should solve the problem.

David Mok

You may have better luck posting your client/server questions in the
database.sql newsgroup where client/server issues are handled.

Bill

--

Bill Todd - TeamB
(TeamB cannot respond to email questions. To contact me
 for any other reason remove nospam from my address.)

The problem is that SQL Server does not increment the counter for the field
until the record itself is inserted. When you call Insert/Append on a
TQuery, it doesn't do anything to the Server until you Post the record, so
Delphi cannot know what the value is.  The only way around that I have found
is setting the field's Required property to false then after post of the
TQuery, you MUST refresh the record and relocate back to it so that you now
have the new Identity value (I believe it has to do with a multi-user
concern. How could the BDE return the next identity value when you call
Insert? There's a lag between Insert and Post, and if a different user
called Insert, would it get the same number?). The only way to really do
that is to have another field that is unique so that you can locate back to
it (ex: VendorID, VendorNum, VendorName are the fields for a Vendor table.
VendorID is the identity and VendorNum is the unique value. AfterPost you
save the value of VendorNum, refresh the Query, then locate back to the
VendorNum).

Now with a unique value, one might question why an identity field? Easy. The
Identity field should be hidden from the user, an internal field used for
data integrity. In the above situation, a child table called Invoices would
have a VendorID field which links to Vendor's VendorID. With this value
hidden from the user, you never have to worry 'What if they change the value
of VendorID, do I have to go through all invoices and change their IDs?'.
Also, VendorNum is unique, what a user would expect, but they can at any
time change the value without breaking the system.

-BKN