I have a program I am trying to get ready for potential users to download and test. This is a program developed in Clarion For Windows (6.3). The testing database is a MS-SQL2005 system which is hosted on a shared server at discountasp.net and the server is located in Los Angeles. My users will most likely be located in Australia.
The problem I saw was the initial time it takes to make a connection to the remote database, and then a further delay with each Table I was opening. These turned out to be two separate issues.
The time taken to establish the initial connection was in the order of 20+ seconds. The connection was being attempted before the main APPFrame screen was being displayed. So expecting someone to start a program and wait 20+ seconds before the first screen response was not going to work. This lead me to build a separate “Starter” program with just one screen that received staged updates from the main program, and then once the AppFrame opened, the “Starter” program simply closed, or displayed any error applicable. The Starter program also had a Seconds Elapsed display and a notice that they may need to wait 20 seconds to connect to the database.
But why was this initial connection taking so long? I could fire up MS-Studio Express and connect in about 4 seconds. It was only the Clarion program that was very slow to connect. This I would research further and eventually solve. See below.
Slow File Opening:
The time taken to open a Browse/List screen was also slow. It was taking about 5 seconds per table to open. Again, this is just too slow. I solved this by adding the Driver switches /FASTCOLUMNFETCH = TRUE to most tables. That has helped. I also set the program to Keep Files Open and I opened a few of the larger tables (those with more columns, not rows).
After spending several days fiddling with the various Driver switches, I was resigned to the fact that it would take 20+ seconds to connect. I started looking for another closed SQL server that would be hosted in Australia. Then, along came Christmas and I took some time off from the development computer. I was relaxing out-doors and just for kicks, decided to try running the program from a 10″ netbook with an Atom processor and on a local wireless network. I started up the program, which worked just fine, and got connected to my Los Angeles database server in about 4 seconds. Could not believe my eyes! Looked at the data and yes, this was indeed coming from the LA database. This little netbook had no database stuff loaded, no MS-SQL and had very few programs installed. Basically it had IE and Firefox for travelling.
So, back to the development PC which could not be 20 seconds slower than the netbook.
I tried several things… Stop all running MS-Servers, Stop a bunch of system services that were running (pretty much anything that looked like a network service). Still I could not get any faster connection from the PC.
Next I remembered someone on the Clarion Database forum had mentioned SQL Native Client. This certainly was not installed on the netbook. But it was on my PC. I had another notebook PC laying around that did have some SQL stuff installed. It was running MSSQL2005 database. I tried running my program on that notebook and it also would connect in 4 seconds. The laptop also had MS SQL Native Client installed, albeit an older version of SQLNCLI.dll. OK, after backing up my newer SQLNCLI.dll I copied the older one from the Laptop to my Development PC. Testing the program again I was still taking 20+ seconds to connect. Then I renamed the file SQLNCLI.dll (located in \windows\system32 ) and tried again. This time I finally managed to connect in about 4 seconds. I put the original SQLNCLI.dll back and connection time again went out to 20+ seconds.
So there was a problem with the SQLNCLI DLL that was causing the problem. I researched this in several places on the internet and found one other report of this problem. But there was no resolution there.
Next I went to Control Panel, and un-installed SQL Native Client. Now I was back to 4 second connect times. OK, Let’s put the Native Client back in. So I downloaded the latest MSSQL2005 version( which turned out to contain the exact same DLL that I was having problems with, and now I was able to connect in about 4 seconds each time the test program started.
MS SQL Native Client (or a related setting) had been the problem all along. By removing and re-installing I had solved the major connection problem. But I had wasted about 4 days getting to that stage! Oh well, that’s computing.