UX LIST won't save data - "No work to do (No dirty fields in table)"

[RichCPT]

AlphaAnywhere Build 3962, in Working Preview mode, won't synchronize the changes in my LIST to the server. It tries to synchronize, but my LIST just gets redrawn with its original data and the list debugging control displays the following:

SQL Commands for Row: 2 (Primary key: 6039)

Table alias: 'dr'.
No work to do (No dirty fields in table)
Table alias: 'LkDoBW'.
No work to do (Table is readonly)
(... previous 2 lines are repeated for remaining 12 lookup tables ...)

When I look at the list debugging window right after I have saved changes from detail view to the LIST (but not yet to the server), I see that my UX debugging info has been truncated, compared to what I see from a UX and LIST built strictly from Alpha's genies. The debug info from My list is missing the following:

"_hasServerSideError": false,
"_serverSideErrors": false,
"_flagServerSideErrorInChild": false,
"_hasWriteConflictErrors": false,
"_hasGlobalErrors": false,
"_flagWriteConflictErrorInChild": false,
"_flagGlobalErrorInChild": false,
"_dirtyImages": false,
"_writeConflictErrors": false

When I click the button to save changes from the list to the server my list dumps the following to the debug info box:


The Genie generated UX and List dump the following after saving list to server:

SQL Commands for Row: 2 (Primary key: 6039)

UPDATE dbo.DocumentResponses SET [drEditCombo_Resp] = :new_drEditCombo_Resp WHERE ([drDocumentResponse_SysID] = :primaryKey_1) AND (drEditCombo_Resp = :old_drEditCombo_Resp)

I don't see why the server thinks the data submitted from my UX does not contain any dirty fields in row #2 and that there is nothing to be saved. The on-screen indicators show the row is dirty. The data in the debug window shows the field I'm updating (drEditCompo_Resp) has an "old" value that is different than the current value. How is alpha server determining when there are fields to be updated or not?

[peteconway]

Re: UX LIST won't save data - "No work to do (No dirty fields in table)"

Rich I stayed on 3922, thought there was to much going on with the builds to jump now.. anyhow - you should send a test case and report the issue. Looks odd.

[RichCPT]

Re: UX LIST won't save data - "No work to do (No dirty fields in table)"

BTW, this (AA thinking there is 'No work to do' during a sync to server, even though field values have been changed.) was solved by replacing an Argument in the SQL SELECT clause with an extra table lookup. I was using an argument in a calculated SELECT expression because the parent component had passed that value to the UX and I didn't want to bother adding an extra table to the LIST. I already have way too many (12) lookup tables. Another solution would be to use the LIST's "Computed Columns" property and do the calculation in JavaScript.

When the LIST is connected to an Access database the code works, but when connected to a MS SQL Server 2008 database the same code does not work. Something in the underlying code that the AA Server uses to calculate if there are any field (column) value changes, behaves differently between an Access DB and a MS SQL DB. I assume the code is doing more than just relying on the OLD vs. NEW values submitted by the workstation. It must be either rereading the record from the DB and messing up the read when an argument is included in a column expression or it is reading meta data about the server columns and Access and SQL give it different information about the calculated column. Something about that calculated column expression makes AA think there are no data changes when using MS SQL even though the submitted data contain different OLD and CURRENT values.

It does not make any difference if I explicitly configure the calculated field to be read-only in the LIST's Detail view or not.

Also, for some strange reason the code does work in MS SQL when I remove all the lookup tables from the LIST's SQL statement, even though all the lookup tables are marked as read-only in the LIST's Detail Table Properties!

I reported a similar problem to Alpha about using Arguments in the SELECT clause (not the WHERE clause) in a Grid component three or four years ago and that problem, too, did not occur when using Access. At that time, I believe, the response was that the problem was too deep in the data driver to get fixed. Although, I think the top level logic could be changed - if only "dirty" fields are going to be changed, or checked for write conflicts, then why should the other fields (like this calculated expression) have any affect on deciding if there are any changes to be applied.

I love the trick of passing arguments directly into the SELECT clause portion of the SQL statement and getting them echoed back, straight-away or after applying a SQL function / expression. I use the technique in reports and on-screen to create scaled bar graphs. The bar graphs are scaled to spread the customer's data values evenly across the available space for the graph on the window or page. I will just have to remember to not pass arguments to the SQL column expressions; I'll have to make sure any value I want to pass can just be gathered from some table in the DB by the SQL statement instead of passing as an argument.