# Using TURBOSQL driver string for a normal SQL table? **URL:** \ **Category:** questions\ **Tags:** sql\ **Created:** [September 19, 2022, 8:48am UTC](https://clarionhub.com/t/using-turbosql-driver-string-for-a-normal-sql-table/5431 "2022-09-19T08:48:44Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![Clarion\_clarion](https://clarionhub.com/user_avatar/clarionhub.com/clarion_clarion/32/636_2.png) [@Clarion\_clarion](https://clarionhub.com/u/Clarion_clarion)\ **Post date:** [September 19, 2022, 8:48am UTC](https://clarionhub.com/t/using-turbosql-driver-string-for-a-normal-sql-table/5431/1 "2022-09-19T08:48:44Z")
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? ---
**Author:** ![seanh](https://clarionhub.com/letter_avatar_proxy/v4/letter/s/4af34b/32.png) [@seanh](https://clarionhub.com/u/seanh)\ **Post date:** [September 19, 2022, 12:59pm UTC](https://clarionhub.com/t/using-turbosql-driver-string-for-a-normal-sql-table/5431/2 "2022-09-19T12:59:05Z")
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 ---
**Author:** ![Rick\_UpperPark](https://clarionhub.com/user_avatar/clarionhub.com/rick_upperpark/32/346_2.png) [@Rick\_UpperPark](https://clarionhub.com/u/Rick_UpperPark)\ **Post date:** [September 19, 2022, 2:11pm UTC](https://clarionhub.com/t/using-turbosql-driver-string-for-a-normal-sql-table/5431/3 "2022-09-19T14:11:58Z")
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. ---
**Author:** ![jslarve](https://clarionhub.com/letter_avatar_proxy/v4/letter/j/e480ec/32.png) [@jslarve](https://clarionhub.com/u/jslarve)\ **Post date:** [September 19, 2022, 2:13pm UTC](https://clarionhub.com/t/using-turbosql-driver-string-for-a-normal-sql-table/5431/4 "2022-09-19T14:13:33Z")
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. ---
**Author:** ![anon23294430](https://clarionhub.com/user_avatar/clarionhub.com/anon23294430/32/3829_2.png) [@anon23294430](https://clarionhub.com/u/anon23294430)\ **Post date:** [September 19, 2022, 4:08pm UTC](https://clarionhub.com/t/using-turbosql-driver-string-for-a-normal-sql-table/5431/5 "2022-09-19T16:08:40Z")
> [@jslarve](#): > > as a generic table to receive whatever columns that you want at the time, you could run into issues with data conversion. 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? > [@seanh](#): > > turbosql just stops the driver from looking at the table in SQL and comparing it to the definition in Clarion. 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) ---
**Author:** ![jslarve](https://clarionhub.com/letter_avatar_proxy/v4/letter/j/e480ec/32.png) [@jslarve](https://clarionhub.com/u/jslarve)\ **Post date:** [September 19, 2022, 4:23pm UTC](https://clarionhub.com/t/using-turbosql-driver-string-for-a-normal-sql-table/5431/6 "2022-09-19T16:23:41Z")
> [@anon23294430](#): > > 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? 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 🙂 ) ---
**Author:** ![Jane](https://clarionhub.com/letter_avatar_proxy/v4/letter/j/ecb155/32.png) [@Jane](https://clarionhub.com/u/Jane)\ **Post date:** [September 19, 2022, 9:47pm UTC](https://clarionhub.com/t/using-turbosql-driver-string-for-a-normal-sql-table/5431/7 "2022-09-19T21:47:27Z")
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 ![BrowseSql1](https://clarionhub-uploads.s3.eu-north-1.amazonaws.com/original/2X/4/45a4f5b1408fa920c4f8fc3f9e540aaa9adac2e1.png) ![BrowseSql2](https://clarionhub-uploads.s3.eu-north-1.amazonaws.com/original/2X/c/c3b9518b03202d62d5cd864ddcf8ac08dde41c1c.png) ---
**Author:** ![Clarion\_clarion](https://clarionhub.com/user_avatar/clarionhub.com/clarion_clarion/32/636_2.png) [@Clarion\_clarion](https://clarionhub.com/u/Clarion_clarion)\ **Post date:** [September 20, 2022, 6:26am UTC](https://clarionhub.com/t/using-turbosql-driver-string-for-a-normal-sql-table/5431/8 "2022-09-20T06:26:19Z")
> [@Jane](#): > > Rick Martin’s _brilliant_ SQL disconnect process do you have a link, please? ---
**Author:** ![Jane](https://clarionhub.com/letter_avatar_proxy/v4/letter/j/ecb155/32.png) [@Jane](https://clarionhub.com/u/Jane)\ **Post date:** [September 20, 2022, 4:38pm UTC](https://clarionhub.com/t/using-turbosql-driver-string-for-a-normal-sql-table/5431/9 "2022-09-20T16:38:14Z")
It’s the second “interim session” toward the bottom of this page: [https://www.cidc2020.com/IndexPage](https://www.cidc2020.com/IndexPage) ---
**Author:** ![CarlBarnes](https://clarionhub.com/user_avatar/clarionhub.com/carlbarnes/32/1859_2.png) [@CarlBarnes](https://clarionhub.com/u/CarlBarnes)\ **Post date:** [September 20, 2022, 6:38pm UTC](https://clarionhub.com/t/using-turbosql-driver-string-for-a-normal-sql-table/5431/10 "2022-09-20T18:38:38Z")
> [@Jane](#): > > [https://www.cidc2020.com](https://www.cidc2020.com) 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. > [@CIDC Africa 2020 (in 2022) starts Thursday September 22 - Time Schedule for USA](https://clarionhub.com/t/cidc-africa-2020-in-2022-starts-thursday-september-22-time-schedule-for-usa/5429/9): > > I just noticed that CIDC 2020 Registrations close tomorrow Tuesday September 20. Price is $300 which gets about 50 hours of Clarion content Here’s Bruce’s post on 9/5 from Discuss.SV Hi All, So CIDC 2020 finally happens this month on September 22-25. Onsite registrations will close this week - but online registrations will be available up to the 20th. If you aren’t already registered (for online, or onsite) then see [https://cidc2020.com](https://cidc2020.com) - Online registrations are especially good value th… ---
**Author:** ![Clarion\_clarion](https://clarionhub.com/user_avatar/clarionhub.com/clarion_clarion/32/636_2.png) [@Clarion\_clarion](https://clarionhub.com/u/Clarion_clarion)\ **Post date:** [September 22, 2022, 8:41am UTC](https://clarionhub.com/t/using-turbosql-driver-string-for-a-normal-sql-table/5431/11 "2022-09-22T08:41:14Z")
> [@Jane](#): > > It’s the second “interim session” toward the bottom of this page: [https://www.cidc2020.com/IndexPage](https://www.cidc2020.com/IndexPage) this one? ![image](https://clarionhub-uploads.s3.eu-north-1.amazonaws.com/original/2X/5/58e6ec3432605a5d235c27dcd6b62396b05b2397.png) what do you suppose I can get from that information? there is no link, no downloads… ---
**Author:** ![JonW](https://clarionhub.com/user_avatar/clarionhub.com/jonw/32/1344_2.png) [@JonW](https://clarionhub.com/u/JonW)\ **Post date:** [September 22, 2022, 4:06pm UTC](https://clarionhub.com/t/using-turbosql-driver-string-for-a-normal-sql-table/5431/12 "2022-09-22T16:06:53Z")
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. ---
**Author:** ![Jane](https://clarionhub.com/letter_avatar_proxy/v4/letter/j/ecb155/32.png) [@Jane](https://clarionhub.com/u/Jane)\ **Post date:** [September 22, 2022, 4:37pm UTC](https://clarionhub.com/t/using-turbosql-driver-string-for-a-normal-sql-table/5431/13 "2022-09-22T16:37:20Z")
> [@Clarion\_clarion](#): > > what do you suppose I can get from that information? there is no link, no downloads… Link: [https://www.cidc2020.com/RegisterForm](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](https://clarionhub.com/t/using-turbosql-driver-string-for-a-normal-sql-table/5431/10)