New Twist: Changed by another station

1

Using v13845 w/ PostgreSQL.

I have dealt with the Changed by Another Station error before and managed to track down the problem, but am scratching my head over the off & on errors I see for one user.

When changing the quantity or price on some line items, the user will get the error. However, if the same line item change is done from a different machine using the same user login, no error occurs. I am also unable to duplicate the problem on my development machine using the same permissions.

The user’s machine is relatively new with regular Windows updates.

Any wild guess suggestions?

2

Hi

I don’t know the answer off hand, but might their be more involved than quantity and price.

If there is a time field at all in the row being inserted?

I’ve found you can get the changed by another station when the time fraction on the backend doesn’t match the time being sent from clarion.

So if I remember clarion TIME is HH:MM:SS:MM, so the fraction part is just two digits. The default as far as I know if the TIME filed is created on Postgres is 6 digits, so it could be a case that the two values (stored and in your record) do not match because of this.

Mark

3

There is a PG modify timestamp, but why this would come into play for one machine and not another would be the question. It is also set to READONLY in the external name.

4

Yes it can. Due to the precision difference between full timestamp and clarion. Clarion will add a where field <> oldfield value to the update, and 0.01 <> 0.012

Change the Posgres side to Timestamp(2) and that solves that problem

5

Anyone please correct me if I am wrong, but by adding READONLY to a field, I do not believe that field is included in the buffers equal check upon which the error is based.

6

I don’t think READONLY has any impact on the watch/concurrency check. You can control which columns are used for the watch command by adding | WATCH to the external field name. If any column as the WATCH attribute, then only columns with WATCH are used.

7

If that is the case, it does not seem that a READONLY timestamp field would cause the problem because ALL editable fields have the WATCH attribute.

8

Yes all the fields go into the update statement for the concurrency check, but only fields where the value stored by clarion and the value in the database are different (like due to a truncation problem) are going to cause Clarion to pop that error. Clarion asks the database to update the record where and the server replies back:

I changed 0 records because none of them matched. So Clarion thinks the record in the database must have changed, when really it just didn’t store the complete value of the timestamp, so it doesn’t match what is in the database.

Not sure that’s your error, but maybe you’ve just been lucky on the other machines?

9

This error also occurs if the language for non unicode programs (Control Panel - Region - Administrative tab) is not set the same on MSSQL Server with Database Collation. If the row loaded into the Form in any field (string or cstring) contains any of the accented characters (Č,č,Ć,ć,Ž,ž,Šš,Đ,đ). Check how the language is set for non unicode programs on the computer reporting this error.

​

10

Because the timestamp is not critical on the Clarion side, I removed it from the table in the DCT without a change in results.

Wondering about adding code to capture & report the DCT field name that is causing the error. I am sure that could be beneficial to many.

Thank you. Your responses here are always appreciated.

11

Will definitely check on this. Given our international research staff, accented characters and heavy use of scientific units in specifications is common. Thank you for the suggestion.

12

That’s a good question. I think it’s something that you would probably want to write a template to do.

From your normal Clarion program you don’t have any information about the field/column that caused the problem. Clarion just knows it expected one record to be updated and the server tells it that it found 0 records to update.

The information about what is in the file/views buffers that the WATCH statement stores is maintained by the file driver, and not accessible to you, the programmer. The WATCH is armed in the BrowseClass.UpdateViewRecord.

If you wanted to figure out the column causing the problem, I think what you would have to do would be:

Write your own version of the Watch statement that stores the file buffers – note that the Watch is followed by a reget, and the help for that says:

REGET re-loads all the VIEW component files’ record buffers with complete records. It does not perform the relational “Project” operation.

You’d presumably call your version of the watch before the parent call of the browseclass.updateviewrecord.

When the update fails, which is in FileManager.UpdateServer (the OF RecordChangedErr branch), you would want to call your diagnostic routine. That routine would probably loop though the fields one at a time, and construct a gradually expanding select statement, submitting each one until the server tells you it can’t find the record. In pseudocode, something like:

stmnt = ‘select count(*) from where 1=1’
for field in file
stmt = stmnt & ‘and ’ & field ’ = ’ <storedfield_value>’
count_return{PROP:SQL} = stmt
if count_return:recs = 0
return 'The problem field was ’ & field
end
end ! loop

So, as I mentioned, probably template territory, because you don’t want to be writing that code by hand. Beyond my talents, but probably not really that hard. You want to keep adding the columns because a select on each column alone might return a record, but with all the columns combined, it doesn’t.

1 Like