Re: EOF inserts PK automatically (Modified by Kieran Kelleher)
Re: EOF inserts PK automatically (Modified by Kieran Kelleher)
- Subject: Re: EOF inserts PK automatically (Modified by Kieran Kelleher)
- From: Karl <email@hidden>
- Date: Mon, 08 Nov 2004 08:35:18 -0500
We have used the same approach but put the code in a stored procedure.
By adding a trigger to the table that is conditional on a null or 0
value in the PK column, the trigger gets fired and populates the
primary key. Other code expecting ID column behaviour works correctly
since other SPs still get the new pk value returned to them.
Karl
On Nov 6, 2004, at 9:44 AM, Kieran Kelleher wrote:
This bounced due to size .... here is a resend...
-----------------------------------------------------------------------
-------------------------
Sako,
We have a similar situation where "other" applications other than WO
interact with the database.
The solution here is to programmatically do inserts following the
exact same SQL scheme as WO does.
SELECT PK from eo_pk_table where NAME='tablename' for update;
In code calculate the new pk, myPk = PK+1
Then immediately update the eo_pk_table...
UPDATE eo_pk_table set PK=myPk where NAME='tablename'
Now put myPk in your record and insert it at you leisure since you
have already "reserved" this pk for your "other" app.
We wrote a VB class for managing the eo_pk_table from external VB
based apps.
With regards Access, you need to prohibit record insert privileges for
the user/pwd used for Access ODBC connections.
Also remove auto increment in your database tables .... that feature
in the case of WO apps might be useful for initially importing stuff
from command line to populate a PK or for tables that are read only
entities for WO and being inserted from one external source.
Regards, Kieran
________________________________________________________________
Dev Config = OS X 10.3.5 / Java 1.4.2_05 / WO 5.2.3 / XCode v1.5 /
MySQL 4.0.20 / Connector-J 3.0.11
Deploy Config = OS X 10.3.5 Server / Java 1.4.2_05 / WO 5.2.3 / MySQL
4.0.20 / Connector-J 3.0.11
My Blog: http://webobjects.webhop.org/
On Nov 6, 2004, at 7:10 AM, Sako! wrote:
Hello Chuck,
thank you for answering.
Chuck Hill wrote:
On Nov 5, 2004, at 1:42 AM, Sako! wrote:
Hello Pierre,
i have MS sql,
what do you mean with "Other applications you have would do best
to rely on the same sequence."?
how can i rely on the same sequence?
the real problem is, i create the object in WO add it to the EC, at
this time the Object has correct PK(hopfullely).
No. At this point the object has an internal, temporary EOGlobalID.
The PK is null.
In fact temporary EOGlobalID or real PK, its not very important for
me. what i need is that the EOF writes the correct PK in the DB.
before i call EC.SaveChanges(). another Application has already
inserted a row in the Table with the same PK. after that WO tries
to insert row with invalid PK.
this problem is also explaind in the WO documentation unfortunately
without really good solution :(
I don't know where you got that, its wrong. The real PK is
generated during save changes as part of a transaction. There is
no danger of duplication. PK numbers can be skipped but never
duplicated.
I think i miss something or something is here wrong.
When i don t set the PK as a ClassProperty, EOF creates its own table
"EO_PK_TABLE" in the database, and saves the last PK in the column
pk.
Another applications like ACCESS (what i really have as another
application) for example do not use this technique.
let me give an example:
1. EOF adds a row with the PK "27", and CHANGES the pk column in
the table EO_PK_TABLE to "27"
2. ACCESS adds a row with the PK "28".
3. EOF does not mention what happens to the table and pk. tries to
write with a PK "28" <== which is already used.
Mr. Chuck, i know you are experienced developer here, but I am sure
what I am telling you and its 100% correct.
I cant change ACCESS now. its expensive and complicated.
WO must be flexible with the database and ACCESS.
So I thought I use the database itself.
There is a feature in MS-SQL <IDENTITY>, what ALWAYS allows the
database to create the PK automatically.
The problem is, this works only if all applications never try to
write in the PK column.
Its possible and easy to make ACCESS stop write in the PK column. And
now my question: "how can i make EOF stop inserting the PK?"
This PK conflict is even in the WO books a big problem, even Apple
has no good suggestion for that.
If you have any suggestions for me please let me know.
In EOF we trust.
Chuck
Regards.
Sarkis.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40mac.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden