Ok this is the thing. We have a SQL server running on our computers at work. This new PC i assembled recently has to connect to this dbase s/w called ACT 1000 which manages workorders. Anyway. The connection to the SQL server went fine, but now when i actually run the s/w and it verifies all the connections, its just all so slow. A different computer which actually runs the same s/w connects to this SQL based server fine. And runs fine too. No speed issues.

But this ones just so bloody snail paced. I dont seem to get the reason. We resetted the server and even ran some tests. All machines run Win XP Professional. The problematic clients a P4 based machine, dell optiplex.

Please help !

What’s your setup like? Is this just one problematic workstation or a bunch?

Could you say more about how the clients connect to the server, whether it’s over TCP/IP or named pipes, whether your app uses BDE and what SP level the XP workstations are, domains, etc? I don’t know anything about ACT 1000 or your environment.

What is the setup like? How does the workstation connect to the server? via TCP/IP? Named pipes? Is it in a domain or AD forest?

My bad drachen.

We connect using SQL, MSDE is not installed at this moment. The client configuration is TCP/IP. The Data Source Name is ‘sndata’ by default which is set using the ODBC Data Source Administrator. It allows us to connect us to connect to the Server’s IP. After this connection is made, ACT scans for connections, and thats where the problem starts. It does complete, but takes forever. After that the program freezes, modules wouldnt load or take time.

ACT 1000 is basically a workorder software which is installed over a multi pc environment so that work orders can be shared and viewed, or edited as and when required. This saves time, and work load gets shared. The server holds the dbase, sndata. Your asked for a password before the s/w loads, thats it.

I’d make sure that the problematic client is running the same version of MDAC as the others. If it is, try reinstalling. (for SP2 machines, you have to actually right-click and install the file c:\windows\inf\mdac.inf) You also might want to make sure that you’re not having a name resolution problem. Have you tried putting the IP of the server rather than the name into the DSN?

Yeh the ODBC takes in the IP. Ill try this thing first up tomorrow morning. Let you know. Thanks drachen.

Back to base 1. The software still freezes on me, for some modules. SQL connection is verified and connection tests are successful. MS Access can extract dbase files but there is no interface to display. ACT customer support is most futile. They dont know why the system would freeze, simply.

Drachen ?

[quote author=“writetovarun”]The software still freezes on me, for some modules. SQL connection is verified and connection tests are successful.

For some and not others? Are all the modules looking at the same database? Is the test slow? Have you tried running queries from software other than ACT against that same database on that server? It’s hard to tell, but it’s starting to look like it’s the software install, not the machine that’s the problem.

[quote author=“writetovarun”]MS Access can extract dbase files but there is no interface to display.

What do you mean by that? Are you trying to import a table from the SQL Server via Access? Not a bad idea, but I don’t know what you mean by that last part.

I was trying to access the dbase with MS Access, but the link tables need ACT 1000 to show up as work orders. Im thinking its the installation.

Now that i tried to reinstall the s/w through remote connection, a version conflict message showed up. This is quite significant, the remote connection thingy doesnt allow me to take a snapshot so ill post it tomorrow. The client and the server sides have different builds installed, apparently, since it never showed up before (and i have installed and reinstalled several times before).

May be download the newer version from the support site?

At this point the goal should be to determine fault. As long as you can view the tables in Access at reasonable speed using the machine DSN that ACT uses without problems, I think you’re right in blaming ACT. If you’re getting no juice from the tech support, contact your sales guy and complain.

Yeph that makes much more sense. Ill try to resolve the conflict issue too. Hopefully it will work out.

Cheers drachen. Thank you

Well apparently a few computers use ACT in a different department and they get the conflict message all the time, but all they do is click on OK and resume. So im guessing its got nothing to do with that.

Drachen do you think its a good idea to check the load on the server? Run some tests to see if the client connects fine? I havent got a clue about the server response although the SQL connectivity test on the client do state them to be ok.

Below is the error message that might be of some significance

Honestly, I’m not sure how much more I can help you. I don’t have much experience with the software you have and I don’t know the nuances of that software. It doesn’t seem that you’re having any general SQL server problems if the other clients are using the same tables the same ways as the problematic client. I’m afraid you will have to rely on ACT’s tech support.

Apparently its got something to do with XP. We installed ACT on another computer on the same network, WIN2000 P4 1.8 and it works so so well. XPs a bit heavy on resources anyway yeh? Its faster than all XP machines running the same S/W put together. So monday im going to try a fresh install on a different partition (WIN2000) and lets see.

Cheers.