Information générale
Catégorie:
Base de données, Tables, Vues, Index et syntaxe SQL
Versions des environnements
Network:
Windows 2008 Server
>Hello All.
>
>This one is driving me crazy (OK - I know it is a short drive). I am modifying a Visual ProMatrix application and in one form, if I change the primary key and save it, the changes are correctly cascaded to all the child tables. However, nothing else works after this change of PK. Every time I try to REQUERY() a view, it gives me back the complaint in the title. The goofy thing is that it only does this when running against local views. When I run the same code against remote views, everything is peachy keen.
>
>Also, if I open the data session window (when running against native data), I see a bunch of extra aliases like 'W44', 'W39', etc. that are being opened. DBC() returns FuneralCase.DBF (which is indeed the main base table for the view I am trying to requery. I have confirmed that CaseNo really is a column in the table.
>
>If I do not change the PK and just edit information, it is able to "see" the column CaseNo with no problem. It also has no problem cascading changes of PK when running against SQL Server.
>
>One more piece of information that might be relevant: someone had originally named the table 'Case'. As you might guess, this caused a lot of problems, so I renamed the table to FuneralCase.
>
>Anyone have any ideas?
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?
Chris.
Précédent
Suivant
Répondre
Voir le fil de ce thread
Voir le fil de ce thread à partir de ce message seulement
Voir tous les messages de ce thread
Voir tous les messages de ce thread à partir de ce message seulement