Data Access Worldwide Knowledge Base
Article Text
PROBLEM:
Using the embedded database with Visual DataFlex 11.0.
In a dbGrid, I have a column with a dblist connected to it in order to
provide an easy prompt selection for some hard-to-get data. This, however, is no normal prompt as it is promptlist to a file which is _not_ connected to the current DDO.
All of the connection details required have been set in theprompt_callback method.
For the dbList we are setting the following prompt properties.
- auto_export_state Of hoPrompt To False
- export_item_state Of hoPrompt To False
- Display_Buffer_Msg Of hoPrompt To MakeMySelection
- Load_Buffer_Msg Of hoPrompt To LoadMyBuffer
The list displays fine and works OK in VDF9.1. In VDF11, however, this same code triggers the above error below:
Error
Invalid Use of Non-Main Table
Technical Details
Error Number: 4508
Line Number: 18532
This error appears to be triggered from the Move_Value_Out method on the last FindByRowID method in the method. Line 465 in package Selst_ds.pkg. When debugging I see that ALL parameters have been set correctly except, maybe, the riRowID as that number doesn't tell me anything anymore.
SOLUTION:
This is a new error message we added to the DDs to detect an error condition that used to just get ignored.
You will get this when you attempt to perform a DD operation (most likely a find) for a file that the DD cannot find. This will either be a file that is not part of the DD structure or a child file of the DD performing the find (DDs look up not down for finds). In these cases, the DD really doesn't know what to do. It would do the find but not do anything useful with it (like update your DD).
This would be seen most often when you ask a parent DD to find on a child record. This is probably a programming bug but the programmer would get no clue that they sent the find to the wrong DD - things would appear to work but the child DD would not have the changes.
In your case, I will guess that this is happening because you've set export_item_state to false. This tells the dbList that you are performing a relational update. So, as part of the move out, it attempts to notify the invoking DD and tells it to find a record for a file that it cannot get at.
Up until 11.0, the DD took the message and did nothing useful. This worked for you because you were taking care of the update later. A non-relational update should set export_item_state to true. You probably didn't do that because you were trying to stop the SL from updating the value via the export_item handler.
This is not a relational update, but since backwards compatibility should win out on this, a package change was necessary. VDF11.0 release should accommodate the situation you described just like 9.1.
An alternative way to have coded this would have been to set export_item_state to True and to cancel the Export_item message in the SL. This is the most transparent solution because you would be saying "this is not a relational update but I will handle the updating of this myself".
Note:
Another user reported that he also saw this error happening when having a dbList object on a dbView whose auto_server_state was set to true. This caused the dblist to set its server to a different server than the main_file of the dblist. The error was triggered by row_changing.
Contributed By:
John Tuohy
Company: Data Access Worldwide
Web Site: http://www.dataaccess.com
Email this Article
Email this Article to a Colleague
Send Feedback on this Article to Data Access Worldwide
Copyright ©2010 Data Access Corporation. All rights reserved.
| The information provided in the Data Access Technical Knowledge Base is provided "as is" without warranty of any kind. Data Access Corporation disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Data Access Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Data Access Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply. |