Error message - Please help

Posted by Admin on 05-Aug-2008 06:54

Hello,

I keep on getting an error mesage when I try updating an items quantity on one of my screen, this only happens the first tim I do it though, when I try updating it the second time it allows me with no error. The error message displayed says:

Error:

Tablel: tt-stock_item_maint

Field(s) have been changed by another user. Your change has been rejected.

update cancelled.

I know this is a schoolboy error, I have attached the part of the program it uses when the error message is generated. Any help would be great.

Thanks.

P.s - sorry,i think I attached the wrong file relating to the error, I think the attached procedure is the correct one (updateRecord).

Message was edited by:

kevin hoy

Showdatamessages.p

updateRecord.p

All Replies

Posted by Håvard Danielsen on 06-Aug-2008 12:27

The message comes from the SDO's optimistic locking check and is passed back to the updating object when there is a conflict. I.E. that someone else has changed the same record since it was retrieved by the SDO.

I assume this is not the case and that you get the message due to some error. This could be a bug or you could do something wrong/unexpected.

You would need to dig deeper to find out, but Support is probably the best place to get this figured out..

The only bug I know about in this area is that you would get this message if a character field is stored in the database with trailing blanks. Progress typically trims character data when they are passed from UI and also through other language constructs, so this is very rare. I think the most common case is due to the use of substring when assigning data to database fields. This bug is fixed, but I'm not sure which version. It may even be the next version. Support would know this too.

Posted by Admin on 07-Aug-2008 01:10

Regarding SDOs - a few things we have encountered causing your error message.

An SDO consisting of table1 with a join to table2 in its query:

Only table1 can be updated by the SDO. Usually when we flag table2 for updates as well it causes problems with the SDO.

More importantly, both table1 AND table2 seems to be checked for changes against the DB - resulting in your error message. (Note this applies to all tables/fields referenced in the SDO)

In some cases our business process require that we make updates to table2 as well. So by the time the SDO wants to commit the changes to table1, table2 has changed causing the same message - fields have been changed by another user. So in effect it was our own code causing the problem.

What to look for.

1. Check that the table2 has a minimum set of fields in the SDO and that the "fields used" flag is set for table2 in the SDO. I.e. only the fields referenced by the SDO will be included. This should reduce the number of fields being checked for changes?

2. Make certain that your process does not update any table/field referenced in the SDO before the normal framework commits the data to the DB.

3. Sometimes refreshing the SDO just before committing the changes fixes the issue - something like refreshRow.

Posted by Admin on 07-Aug-2008 03:46

An SDO consisting of table1 with a join to table2 in

its query:

Only table1 can be updated by the SDO. Usually when

we flag table2 for updates as well it causes problems

with the SDO.

Do you have details about the errors you are receiving and possibly the Progress/OpenEdge Version?

I update SDO with joined queries all the time without any issues.

The only thing a developer needs to be aware of is that during creates and deletes the ADM2 super procedures code creates and deletes records in both tables. That may cause issues (triggers preventing deletes in the wrong order or deletions of records that were not supposed to do). A developer needs to control this.

Second: The developer is responsible for filling the database fields in the joined table on create, so that the created row is joined to the created row of the first table. A good location for that is assignDBRow after the RUN SUPER. The records are still in scope and the DB transaction still active.

Posted by Admin on 07-Aug-2008 04:07

We're currently running OE10.1b and Dynamics. We've been experiencing this problem/feature since day 1 on Dynamics (since Progress 9x, Dynamics v2x).

We understood that this is a feature of the Dynamics SDO and that the SBO was intended to overcome such issues - getting to update multiple tables simultaneously. Basically we were told to avoid the situation (flagging more than one table for updates in a SDO), which we still are doing.

The problem/error usually occurs with updates of existing data. It's been a while, but usually our SDO does not save anything on the viewer - no errors on screen is displayed other than our new data being discarded and the old data showed.

Posted by Admin on 07-Aug-2008 06:33

It would be interesting to know who told you to avoid this.

I consider this basic and functional SDO behavior.

The SBO was introduced for larger scenarios and when data normally maintained in different SDO/displayed in different browsers and viewers need to be updated in a single transaction.

Posted by Håvard Danielsen on 07-Aug-2008 07:21

More importantly, both table1 AND table2 seems to be checked for changes against the DB - resulting in your error message. (Note this applies to all tables/fields referenced in the SDO)

Yes, all the fields are considered part of the SDO, also joined read-only tables. This strict interpretation of what is a unit of data is necessary as a default, but there are certainly cases where it doesn't make sense and causes problems.

We added a property to allow you to override this behavior in 10.1C.

NoLockReadOnlyTables can hold a comma separated list of read only tables that not should be locked and included in the optimistic lock comparison during the transaction.

A value of 'all' means that all read only tables should remain no locked and not checked.

The purpose of the 'all' option is to allow you to specify this at the class/super level for all SDOs.

I guess it should have been a field list to be truly flexible, but this also affects locking.

Posted by Admin on 07-Aug-2008 07:54

Well, thats good to know - a SDO should be able to update multiple tables in its query.

Usually when we have a SDO thats not functioning the first thing we do is remove any flags for updates on the secondary tables - which usually fixes our problems.

Ill keep an eye open for other SDOs that causes problems and investigate according to your guidelines you set out.

Thanks!

Posted by Admin on 07-Aug-2008 08:39

This sounds like a really nice feature that will save us a lot of effort!

We'll be looking forward to use NoLockReadOnlyTables.

Posted by Admin on 07-Aug-2008 09:26

Hi, thanks for all your input. The version that were using is 9.1E. Hoping to upgrade fairly soon though. I have attached the error that gets displayed.

[View:~/cfs-file.ashx/__key/communityserver-discussions-components-files/26/error_5F00_message2.doc:550:0]

Thanks again.

Posted by Håvard Danielsen on 07-Aug-2008 10:00

Well, thats good to know - a SDO should be able to update multiple tables in its query.

As Mike points out, this is basic SDO behavior, but the requirement is that there is a one-to-one relationship between the tables. It does not necessarily need to be a one-to-one relation in the database, but the SDO does not support updates to a database record that is represented in more than one SDO row.

I believe this is the main reason for the common misunderstanding that an SDO only can update a single table. This is where the SBO comes in, as it can handle one-to-many relationships in a single transaction.

The SBO also handles one-to-one relationships in separate SDOs. This approach has the benefit of being able to use the ForeignFields for new records, but it is often harder to work with when it comes to linking in the UI and it has more performance overhead than a single SDO with two tables.

The main purpose of the one-to-one relationships support in SBOs is to reuse business logic in an SDO that also need to be used standalone. If this is not the case you are typically better off with SDOs for one-to-one relationships. (There are many other factors that can tip the decision in either direction, so this is not a hard and fast rule)

Posted by Admin on 07-Aug-2008 15:09

As Mike points out, this is basic SDO behavior, but

the requirement is that there is a one-to-one

relationship between the tables. It does not

necessarily need to be a one-to-one relation in the

database, but the SDO does not support updates to a

database record that is represented in more than one

SDO row.

Exactly. We are using SDOs quite often where we store information about the same item in two tables. On is the general item information, the second table holds item infomration related to a single login company. So in the database, there is a 1:n relation ship but as we add CompanyItem.login_company_obj = xyz to the query it becomes a 1:1 relation for the SDO.

In a browse or a viewer we display this as a single row. The separated storage of the item record is nothing a user needs to care about.

Posted by Admin on 07-Aug-2008 15:12

That's exactly the message that has been discussed by Haarvard. So updating to 10.1C will hopefully resolve your issues.

Posted by Håvard Danielsen on 07-Aug-2008 15:41

If your problem is trailing blanks in data then you might resolve this by trimming your data. There's no trim data option, you'd have to do this with a "for each" and trim the field(s). I cannot imagine you ever would need trailing blanks in your database.

The message could also be a side effect of an SDO having more than one enabled/updatable table without following the one-to-one rule and instead having one of the database rows represented in more than one SDO row, in which case an upgrade won't help.

Posted by Admin on 08-Aug-2008 04:48

Hi,

I tried using refreshrow but am unsure where to actually put it within the program, would it be just before the fields get assigned in the updaterecord program, and how would i write this? I didnt actually create the program, but am required to fix this bug, and have just been looking and working out how everything joins together, sorry if I sound like a novice. Also, is anything else required next to assignDBRow so I could test that aswell? Is anyone able to give some snippets of code I could try? I would really appreciate it.

Thanks again for all your input.

Posted by Håvard Danielsen on 09-Aug-2008 14:37

I took a look in the updateRecord procedure and it assigns the BUFFER-VALUE of fields that seem to belong to the temp-table of the browser. The browser's temp-table is the RowObject of the SDO and changes done to it will cause optimistic lock conflicts when you save.

I maybe wrong about this, but in any case, you need to find the cause of your problem before you try to fix it.

This thread is closed