Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
SQLEXEC not working with variable as parameter
Message
General information
Forum:
Visual FoxPro
Category:
Coding, syntax & commands
Miscellaneous
Thread ID:
00445283
Message ID:
00445314
Views:
9
BARBARA -----------------------
Jeff,
Check the original SQL-Server database for the exact spelling/case of "Person".

Have you tried writing the SQLEXEC code as a single line and running this with a macro?
cSQL = [SQLEXEC(lnHandle, 'Select * from Patient', "tCursor")]
? &cSQL

I do this regularly with local data.


I did find the backend is case-sensitive, so Person v. person was an issue (thanx also to Trey for that one). The macro expansion problem is one of the main problems in this whole thing. I've been doing the same thing with local data forever, too, but I can't get the same query that runs locally to run on the backend if I send it as a variable. I have to encase the string in quotes. I had the same trouble with your string suggestion above. Every test query runs fine on the local data, but I get a variety of errors on the remote side.
========================================================================
TREY--------------------------------------------------------------------
Have you tried simply 'person'? The SQL Server may be configured to be case sensitive.

To make sure you have the correct table names, you can get them by using
SQLTABLES(lnHandle, "Table"). The table_name field has the name as it should be referred to.

Also, check your ODBC connection to make sure the Default database is correct.
------------------------------------------------------------------------
Yep, case-sensitivity was one issue, but I'm still having a great deal of trouble sending macros to the back end. The table name is ok, because if I send a quoted string instead of a variable, the query works. And the default database is OK in the DSN, too.


These queries are simply look-up proxies, which is why we tried to use SQL passthru instead of views with their added overhead, but this is so incredibly finicky I think I'll see what it would take to convert the proxies to non-updateable views. I know that slows them down, but this may require a greater SQL wizard than I to get these passthru statements cleaned up, and take more time than we have for the short term. Guess we'll have to classify this as a future performance enhancement :-)

Thanks for your responses. If any breakthroughs occur, I'll pass them along.

-Jeff
Previous
Reply
Map
View

Click here to load this message in the networking platform