# New Twist: Changed by another station **URL:** \ **Category:** questions\ **Tags:** drivers, sql\ **Created:** [November 14, 2023, 1:33pm UTC](https://clarionhub.com/t/new-twist-changed-by-another-station/6773 "2023-11-14T13:33:20Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![totalhip](https://clarionhub.com/user_avatar/clarionhub.com/totalhip/32/1477_2.png) [@totalhip](https://clarionhub.com/u/totalhip)\ **Post date:** [November 14, 2023, 1:33pm UTC](https://clarionhub.com/t/new-twist-changed-by-another-station/6773/1 "2023-11-14T13:33:20Z")
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? ---
**Author:** ![Mark\_Sarson](https://clarionhub.com/user_avatar/clarionhub.com/mark_sarson/32/6132_2.png) [@Mark\_Sarson](https://clarionhub.com/u/Mark_Sarson)\ **Post date:** [November 14, 2023, 3:09pm UTC](https://clarionhub.com/t/new-twist-changed-by-another-station/6773/2 "2023-11-14T15:09:09Z")
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 ---
**Author:** ![totalhip](https://clarionhub.com/user_avatar/clarionhub.com/totalhip/32/1477_2.png) [@totalhip](https://clarionhub.com/u/totalhip)\ **Post date:** [November 14, 2023, 3:35pm UTC](https://clarionhub.com/t/new-twist-changed-by-another-station/6773/3 "2023-11-14T15:35:53Z")
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. ---
**Author:** ![seanh](https://clarionhub.com/letter_avatar_proxy/v4/letter/s/4af34b/32.png) [@seanh](https://clarionhub.com/u/seanh)\ **Post date:** [November 14, 2023, 10:15pm UTC](https://clarionhub.com/t/new-twist-changed-by-another-station/6773/4 "2023-11-14T22:15:30Z")
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 ---
**Author:** ![totalhip](https://clarionhub.com/user_avatar/clarionhub.com/totalhip/32/1477_2.png) [@totalhip](https://clarionhub.com/u/totalhip)\ **Post date:** [November 14, 2023, 11:55pm UTC](https://clarionhub.com/t/new-twist-changed-by-another-station/6773/5 "2023-11-14T23:55:28Z")
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. ---
**Author:** ![Rick\_UpperPark](https://clarionhub.com/user_avatar/clarionhub.com/rick_upperpark/32/346_2.png) [@Rick\_UpperPark](https://clarionhub.com/u/Rick_UpperPark)\ **Post date:** [November 15, 2023, 3:51pm UTC](https://clarionhub.com/t/new-twist-changed-by-another-station/6773/6 "2023-11-15T15:51:40Z")
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. ---
**Author:** ![totalhip](https://clarionhub.com/user_avatar/clarionhub.com/totalhip/32/1477_2.png) [@totalhip](https://clarionhub.com/u/totalhip)\ **Post date:** [November 15, 2023, 7:24pm UTC](https://clarionhub.com/t/new-twist-changed-by-another-station/6773/7 "2023-11-15T19:24:34Z")
> [@Rick\_UpperPark](#): > > If any column as the WATCH attribute, then only columns with WATCH are used. 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. ---
**Author:** ![JonW](https://clarionhub.com/user_avatar/clarionhub.com/jonw/32/1344_2.png) [@JonW](https://clarionhub.com/u/JonW)\ **Post date:** [November 17, 2023, 1:03pm UTC](https://clarionhub.com/t/new-twist-changed-by-another-station/6773/8 "2023-11-17T13:03:39Z")
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? ---
**Author:** ![vlada.unisoft](https://clarionhub.com/user_avatar/clarionhub.com/vlada.unisoft/32/4601_2.png) [@vlada.unisoft](https://clarionhub.com/u/vlada.unisoft)\ **Post date:** [November 17, 2023, 1:46pm UTC](https://clarionhub.com/t/new-twist-changed-by-another-station/6773/9 "2023-11-17T13:46:04Z")
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. ​ ---
**Author:** ![totalhip](https://clarionhub.com/user_avatar/clarionhub.com/totalhip/32/1477_2.png) [@totalhip](https://clarionhub.com/u/totalhip)\ **Post date:** [November 17, 2023, 3:05pm UTC](https://clarionhub.com/t/new-twist-changed-by-another-station/6773/10 "2023-11-17T15:05:24Z")
> [@JonW](#): > > 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. Because the timestamp is not critical on the Clarion side, I removed it from the table in the DCT without a change in results. > [@JonW](#): > > 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. 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. ---
**Author:** ![totalhip](https://clarionhub.com/user_avatar/clarionhub.com/totalhip/32/1477_2.png) [@totalhip](https://clarionhub.com/u/totalhip)\ **Post date:** [November 17, 2023, 3:11pm UTC](https://clarionhub.com/t/new-twist-changed-by-another-station/6773/11 "2023-11-17T15:11:26Z")
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. ---
**Author:** ![JonW](https://clarionhub.com/user_avatar/clarionhub.com/jonw/32/1344_2.png) [@JonW](https://clarionhub.com/u/JonW)\ **Post date:** [November 17, 2023, 3:58pm UTC](https://clarionhub.com/t/new-twist-changed-by-another-station/6773/12 "2023-11-17T15:58:51Z")
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 ’ = ’ \’ 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.