Hi,
I went back to my original test case to add the ScriptingProvider. It did not reproduce the access violation. I did some more work with that test case. I discovered that my AutoRefresh column has to be selected as LogChanges or I get an error that the column is not in the delta. I can set it to Server AutoRefresh = true, Log Changes = true, and Read Only = true; and it works. In both cases, I did not get the access violation with the scripting provider. This column is a DATETIME column that is set by the server, with a default constraint, and is not edited by the client.
I went back to my main application and copied the same column settings for my autorefresh column. I get a “Details for Change…” dialog, with an error: “Cannot find a table field called ‘REQUEST_NUMBER’ in the mappings collection.” Request # is an MS SQL Server computed column. It is a VARCHAR column that is computed with a user defined function.
I am giving these extra details because both columns were set to the same Schema Modeler Flags of: Server AutoRefresh, LogChanges, and ReadOnly. Those properties were imported from the Schema into the TDAMemDataTables. They are different data types, but have exactly the same Flags.
The TDAMemDataTable for my main application returns 82 columns. The only change that causes the “mappings collection” error is changing REQUEST_NUMBER from Server AutoRefresh = false to Server AutoRefresh = true. I have noticed that if a TDAMemDataTable contains a LookupField and the LookupSource is not active, I will get an error. I have also had issues with DA and MS SQL Server specific data types, such as DATE and SMALLMONEY.
Two more differences between the test case and the actual app. 1) The test case operates directly against the table and the app uses an updateable view. However, I believe that I had the same problem in my app, with using the table. 2) The test case just opens the TDAMemDataTable and the app uses a DA SQL with TableRequestInfoV6.
If test cases can work with Server AutoRefresh and ScriptingProvider, it makes me wonder if the problem is not cause by something else in the schema, but may be set off by the Server AutoRefresh on this particular column.
I am going to keep digging into this and trying to fix or reproduce the errors. However, I may not be looking in the right place, if it is something else in the schema. I am not really sure where to look or what may cause problems for DA.
Thanks,
David