Hello Reinhard, Thanks a lot!
I can't use oids due to database layer design. (All queries going thrue stored functions). I think that calling counter before insert with explicite id is stress-safe. Even when client makes this work. I am going to make it in stored procedures and return primary key of new inserted row to client. Then client will use this primary key to update details. -- Best regards, Oleg mailto:[EMAIL PROTECTED] ----- Original Message ----- From: Reinhard Mueller <[EMAIL PROTECTED]> To: Oleg Noga <[EMAIL PROTECTED]>, [email protected] Date: Monday, December 10, 2007, 3:29:12 PM Subject: [GNUe] cascade insert into master detail RM> Hi, Oleg! RM> Finally I had the time to look into this. RM> Am Dienstag, den 04.12.2007, 19:17 +0200 schrieb Oleg Noga: >> When i am only inserting new spr_user row it is ok. >> When i am only inserting new spr_usergroup row it is ok. >> When i am trying to insert a user with newly entered group list i have >> exception: RM> You are using Posgres, which doesn't have OIDs for user tables by RM> default. RM> So whenever you insert a new master record, the Postgres server assigns RM> it a new user_id on its own. The client (gnue-forms) has no way of RM> finding out what user_id the newly inserted record got. So gnue-forms RM> also has no way of setting that user_id in the detail records. RM> If you enable OIDs, Postgres tells gnue-forms about the OID of the newly RM> inserted record, and gnue-forms can query the record again using that RM> OID and find out about the user_id assigned. RM> To enable OIDs, you have to: RM> 1. CREATE TABLE ......... WITH OIDS; RM> 2. have "use_oid = yes" in your connections.conf RM> I have tried it, and it works if you do it that way. >> What is 'rowid' datasource attribute? RM> Please forget about that attribute, it will soon be deprecated. >> How datasource behaviour depends on primarykey, primarykeyseq and >> rowid attributes defined or not? RM> primarykey: will be used to find a record again after it has been RM> changed. Gnue-forms relies on the assumption that the primary key of a RM> record never changes through triggers or stored procedures. This concept RM> fails for newly inserted records if the primary key is set from a RM> sequence (see above). If a rowid is available, it is preferred over the RM> primary key, since the rowid is guaranteed to *never* change. RM> primarykeyseq: name of a sequence. If set, the client (gnue-forms) will RM> query that sequence from the database and directly set the primary key RM> of a newly inserted record before posting it. This is a workaround for RM> exactly your problem, but it is very ugly: it moves stuff to the client RM> that should happen at the server. I recommend to avoid this at any cost. RM> Thanks, RM> Reinhard _______________________________________________ Gnue mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnue
