Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Error 1806 SQL: Column 'CaseNo' is not found
Message
From
26/11/2013 15:57:41
 
 
To
26/11/2013 09:44:24
General information
Forum:
Visual FoxPro
Category:
Databases,Tables, Views, Indexing and SQL syntax
Environment versions
Visual FoxPro:
VFP 9 SP2
OS:
Windows Server 2012
Network:
Windows 2008 Server
Database:
MS SQL Server
Application:
Web
Miscellaneous
Thread ID:
01588611
Message ID:
01588699
Views:
47
>Are there any SELECT * queries? I know those complain the most when the structure behind them changes.
>Have you used a tool (Code References/GoFish) to look for CaseNo? Does another alias than the ones you're looking at have it?
>Are you using a subquery or temporary table that might have that fieldname?
>Don't know Promatrix; does one of its Business Objects have a reference to that fieldname?

>
>I thank you for trying to be of assistance. However, the point that you are missing is that this behavior is only exhibited after cascading the modified PK to the child tables (which is does successfully). I do believe that if the problem were the view definition, this behavior would occur all the time - not just when the PK changed.
>
>To answer your question about the CaseNo field. Of course it is in other tables - it is the PK of the parent table and the FK of the child tables.
>
>Also, as I said earlier, the exact same code works fine without any problem when running against remote views. This is strictly a native data issue. But I simply cannot figure out what the problem is. The view definition selects 2 fields from the FuneralCase table (yes, one of them is CaseNo) and both fields are in the FuneralCase table. The view can be requeried successfully with no problem (even against VFP data) until the PK is changed and the change is cascaded to the child tables.
>
>VPM relies heavily on metadata. I was wondering if the problem arose because I had renamed the Case table to FuneralCase. But I checked all the metadata and there are no references in it to Case.dbf. The references all now point to FuneralCase.dbf.

The error message indicates a structure issue; it seemed prudent to focus on that.

What were the original and changed PKs? Does it fail for only a specific change or all PK changes?
Does changing the PK back to original value "fix" the problem or stay broken?
Are you running into an accidental keyword, wildcard or end of file?
If you delete and recreate the local view, does the error persist?
Are you using Fox on the local view or SQL Pass Through?

Is tracing the RI code during the update possible?
What is in the additional aliases?

Some more ideas, even if the just eliminate the impossible.
Chris.
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform