[icf-dev] very strange SDO error

HI Mike,

I saw something like this once before. After spending some time debugging

everything, and finding all the correct values in the RowObjUpd tables, but

not in the point where the error came from, we noticed that with the initial

values of some fields in a unique index, the index was violated in the

CREATE of the record... Verify that all your initial values in your fields

do not violate any of your unique indexes on that table. If so, there could

be a faulty record in your table, or maybe you should consider giving one of

the fields a null initial value(?) which will not violate the index at

create. It is difficult to say if this would work for you as it depends on

your database requirements & design etc.

Regards,

Chris

PS: I would like to know if you get the problem solved...

-Original Message-

From: Mike Liewehr

Sent: 10 October 2002 14:18

To: dev@icf.possenet.org

Subject: very strange SDO error

Hi all,

we have a very strange problem with the SDO in dynamics 1.1 Â…

The problem is that when we save a newly created record, we get the error

132 (“record already exists”). But the reason for this is that the SDO

does not

write the correct values to the DB as they are passed in the rowObjUpd

table but rather

an empty record which contains only the initial values. The strange thing

is that in assignDBrow

the data in rowObjUpd is correct, but the data that is commited to the DB

is wrong. It seems as if somewhere

deep in the dungeons of the adm2 a new buffer is created which is then

commited to the db instead of

the record that has been passed to serverCommit.

Another strange thing is that it seems as if the actual write of the

record occurs in the refetchDBrow procedure,

Because when we look at the stack trace this is the procedure that invokes

our DB write triggerÂ… ?!?

This happens only with 1 SDO – however, we can´t find anything special

about this particular SDO.

We spent several days in debugging this but are unable to see what the

problem is.

Does anybody know what the reason for this is ?

Any help greatly appreciated, as this is a real showstopper for usÂ…

Regards

Mike Liewehr

IT focus GmbH

Informationstechnik & Beratung

Schultheiss-Koehle-Str. 1

D-71636 Ludwigsburg

fon: +49 7141 4748 0

fax: +49 7141 4748 11

mailto:mike.liewehr@itfocus.com

http://www.itfocus.com

...we can do IT!

______________________________________

This e-mail may contain confidential information and may be legally

privileged and is intended only for the person to whom it is addressed. If

you are not the intended recipient, you are notified that you may not use,

distribute or copy this document in any manner whatsoever. Kindly also

notify the sender immediately by telephone, and delete the e-mail. When

addressed to clients of the company from where this e-mail originates ("the

sending company ") any opinion or advice contained in this e-mail is subject

to the terms and conditions expressed in any applicable terms of business or

client engagement letter . The sending company does not accept liability for

any damage, loss or expense arising from this e-mail and/or from the

accessing of any files attached to this e-mail.

Mike,

The problem you are experiencing has been reported in Issuezilla under Issue

468 (http://www.possenet.org/issues/show_bug.cgi?id=468).

The problem basically is seen with SDOs based on tables having multiple

component unique indexes. The assignDBRow is assigning fields one by one,

however, when it tries to assign the field forming the index, the assignment

fails, a message is returned and the transaction is undone.

This logic basically needs to be changed to perform a buffer-copy instead of

assigning those changed fields individually.

Don

~~~~~~~~~~~~~~~~~~~~~~~~~

Don Bulua

Inway Software Inc.

Montreal, Quebec

email: dbulua@sympatico.ca

tel: (514) 685-0412

fax:(514) 685-0361

~~~~~~~~~~~~~~~~~~~~~~~~~

-Original Message-

From: Chris Koster

Sent: Thursday, October 10, 2002 8:43 AM

To: dev@icf.possenet.org

Subject: RE: very strange SDO error

HI Mike,

I saw something like this once before. After spending some time

debugging everything, and finding all the correct values in the RowObjUpd

tables, but not in the point where the error came from, we noticed that with

the initial values of some fields in a unique index, the index was violated

in the CREATE of the record... Verify that all your initial values in your

fields do not violate any of your unique indexes on that table. If so, there

could be a faulty record in your table, or maybe you should consider giving

one of the fields a null initial value(?) which will not violate the index

at create. It is difficult to say if this would work for you as it depends

on your database requirements & design etc.

Regards,

Chris

PS: I would like to know if you get the problem solved...

-Original Message-

From: Mike Liewehr

Sent: 10 October 2002 14:18

To: dev@icf.possenet.org

Subject: very strange SDO error

Hi all,

we have a very strange problem with the SDO in dynamics 1.1 Â…

The problem is that when we save a newly created record, we get the

error

132 (“record already exists”). But the reason for this is that the SDO

does not

write the correct values to the DB as they are passed in the rowObjUpd

table but rather

an empty record which contains only the initial values. The strange

thing is that in assignDBrow

the data in rowObjUpd is correct, but the data that is commited to the

DB is wrong. It seems as if somewhere

deep in the dungeons of the adm2 a new buffer is created which is then

commited to the db instead of

the record that has been passed to serverCommit.

Another strange thing is that it seems as if the actual write of the

record occurs in the refetchDBrow procedure,

Because when we look at the stack trace this is the procedure that

invokes our DB write triggerÂ… ?!?

This happens only with 1 SDO – however, we can´t find anything special

about this particular SDO.

We spent several days in debugging this but are unable to see what the

problem is.

Does anybody know what the reason for this is ?

Any help greatly appreciated, as this is a real showstopper for usÂ…

Regards

Mike Liewehr

IT focus GmbH

Informationstechnik & Beratung

Schultheiss-Koehle-Str. 1

D-71636 Ludwigsburg

fon: +49 7141 4748 0

fax: +49 7141 4748 11

mailto:mike.liewehr@itfocus.com

http://www.itfocus.com

...we can do IT!

______________________________________

This e-mail may contain confidential information and may be legally

privileged and is intended only for the person to whom it is addressed. If

you are not the intended recipient, you are notified that you may not use,

distribute or copy this document in any manner whatsoever. Kindly also

notify the sender immediately by telephone, and delete the e-mail. When

addressed to clients of the company from where this e-mail originates ("the

sending company ") any opinion or advice contained in this e-mail is subject

to the terms and conditions expressed in any applicable terms of business or

client engagement letter . The sending company does not accept liability for

any damage, loss or expense arising from this e-mail and/or from the

accessing of any files attached to this e-mail.