Is it a good idea to use TURBOSQL driver string for a normal SQL table not just for prop:sql? I have standard normal MSSQL tables in the DCT. Use them as usual in Browse boxes etc. So will using TURBOSQL increase performance or will give me some kind of problem?
turbosql just stops the driver from looking at the table in SQL and comparing it to the definition in Clarion.
As far as I’m aware thats the only thing it does different. ie No error 47
1 Like
I found that TurboSQL is not safe if you are accessing multiple databases from your application.
You get cross database behavior. Even if each table only ever accesses one database.
1 Like
If you try to use your table in the “customary TurboSQL way”, which is as a generic table to receive whatever columns that you want at the time, you could run into issues with data conversion.
Also, no longer will your column names will be “guaranteed” to contain the same data that they’re supposed to.
1 Like
Cant say I’ve run into that problem personally. Is this like messing up the field numbers of a listbox control which dont match the fields of its queue source?
So if you add new fields to the dct after the existing one’s for a new version of your app, it then becomes possible to run different versions of the app from a single database which has been updated to the latest version.
eg all these versions of the app can run off the version 3 database.
Ver 1 app
Table1
Name String(100)
Address String(100)
Ver 2 app
Table1
Name String(100)
Address String(100)
Phone String(100)
Ver 3 app
Table1
Name String(100)
Address String(100)
Phone String(100)
EmailAddress String(100)
I’m talking about situations where (for example) your query requests a STRING column, but your file’s RECORD contains a LONG at that position. (or whatever other incompatible data types you can think of 
)
I’ve been wondering about this lately as well.
NOT using TurboSQL is quite noisy in its verification of columns.
I’m making a new in-house web app, and the one downside to Rick Martin’s brilliant SQL disconnect process (shown in a CIDC 2020 webinar) is that for each new thread (i.e., go to the next page of a browse), SQL “wakes up” and again requests reassurance that columns are what it expects.
Based on warnings online and in the Clarion docs, I’m too paranoid to try to avoid that. I just plan to crawl under my desk if someone comes around asking why my apps are causing so much noise on the SQL server. (But since I’m the only one here who’ll notice, I feel slightly safe…) The added reliability of Rick’s disconnector for apps that run as a service 24/7 has been pure gold and well worth the additional noise.
These two pics represent a NetTalk browse(using Rick’s disconnect).
The first “declare @p1 int set @p1=180150003…” is for the main table on the browse (app.vwAuditableProviders).
The actual code is pasted into SSMS and run manually in the second screen shot.
What Clarion is doing is to run the stored procedure sys.sp_columns_100 to get information about each column.
Then it uses a cursor to go to the server and one-at-a-time pull back the 23 rows representing the 23 columns in the table.
That means one trip to the server and back for each column, regardless of whether it’s actually used in the browse.
Then (back to the top screen shot) that cursor closes and another is built (180150005). This is for the table that’s used for an EIP droplist for editing one of the columns in the browse. Again build the query, then back-and-forth one row at a time to fetch each column’s information (again, regardless of whether the column is actually used for the EIP).
Random observations, FWIW…
jf
2 Likes
do you have a link, please?
It’s the second “interim session” toward the bottom of this page: https://www.cidc2020.com/IndexPage
Today 9/20 is the last day to register and get access … for a week+. The CIDC team will be busy with the conference.
To see the Interim Session links you must Login. The links are on the Streaming and Presentation pages.
this one?
what do you suppose I can get from that information? there is no link, no downloads…
Yes. To clarify Sean’s comment: Clarion looks at the columns defined in the Clarion dictionary and makes sure they all exist in the database. If the table in the database has other columns too, clarion doesn’t care. Also, to my knowledge, Clarion does not check the datatypes or datasize of columns. So if your version 1 clarion dictionary had address as a string(50) or string(150) it would be happy (in that original check) so long as there was an address column in the table of any size or datatype.
Link: https://www.cidc2020.com/RegisterForm
As detailed in Carl’s post above yours: Using TURBOSQL driver string for a normal SQL table? - #10 by CarlBarnes