SQL server and Terminal Server

[Lorain]

Need some advice on this. Client is running Progression 7.6.100A on MSSQL on a WIN 2000 SP4 server with 2 gigs memory and Terminal Server with about 5 users logging in daily. They just upgraded from DOS ver. 6 BTR. There is a real issue with slow response time and locking errors in OE, POP, and BOM. Any help will be appreciated.

Thanks in advance for help.

Lorraine
lorainst@cs.com

 

[MacolaHelp]

Could be a lot of things. To go all the way from 6x btrieve dos to mssql is a huge jump. Do you know that your files were fine in between? I had huge problems converting some clients from 6 to 7x & discovered a number of files that I simply initialized rather than converted. It's not too late to initialize "unneccesary" files, particularly if they still have access to their old server for a few months until they find out that they don't really need all that audit trail data, etc, on the new server. Also, file validations, while often a major pain in the a$$, can often relieve the performance issues once you get rid of the bloated DB files. Did you also put in the record locking patch for 7.6.100a. If not, let me know & I will email to you. Also, check infomine for many docs on terminal server performance issues.

 

[Lorain]

I don't know if the record locking patch was added or not. I inherited this client.. would ithurt to apply twice? Please send it to me.
Thanks in advance Lorraine
lorainst@cs.com

 

[stravis]

The speed issue can certainly be an issue of slow response time from your SQL Server. Where is MSSQL installed, what is the hardware configuration, and what other services/applications are running on that server?

MSSQL requires quite a bit more resources to run than Btrieve. With MSSQL you get fast response times first with fast SCSI harddrive access, this will give you fast response times with a single user, and then you scale to additional users with memory, processors, and network bandwidth.

Scott Travis
infoSpring, LLC.

 

[Lorain]

WIN 2000 SP4 server with 2 gigs memory. Server is SCSI...RAID. There is a separate drive for the O/S. There are no other apps except SQL Server, Macola 7.6.100A, Crystal 8.5 and the tape backup software...And of course Terminal Services.There is also Norton Antivirus running on the server...Corporate edition. Is that enough info or would you like something specific? 15 users, 5 remote on TS. The users complain that reports are slow. Any suggestions are welcome. Thanks in advance, Lorraine

 

[MacolaHelp]

Reports should be lightning fast in this environment. Did you double check the SQL server setup based on macola's specs? Sent you the locking patch, too, so good luck.

 

[Lorain]

Thanks, I will double check the setup docs. I wasn't around when the server or SQL was setup. Is there any reason we should put TS on its own server/workstation or is it fine staying on the SQL server? We have about 5 or 6 daily users logged in most of the time. I will apply the patch tomorrw evening and see how that helps

Thanks in advance for the helpful advice.

Lorain

 

[stravis]

It would certainly be best to have your Terminal Services users on another server, but sometimes the cost of doing so is too much. How many processors are on this server?

Scott

 

[Lorain]

There is one processor on the server.

Lorain

 

[stravis]

I would say that a single processor on the server is simply not enough given your current configuration. I would suggest testing the speed of Macola without any users logged in to Terminal Services and see what kind of performance you can get. If you have a significant speed increase, I would suggest moving your Terminal Services users to another server.

On the issue of slow reports; which reports are running slow? If these are Crystal Reports what kind of database connection are you using? ODBC or OLE DB?

Scott Travis
infoSpring, LLC.

 

[MacolaHelp]

TS should be on another server, in my opinion. You really are not supposed to run the macola client from the SQL server, but from an attached workstation. Your TS server should be configured so that each macola log in has 128-256k RAM for each virtual client after loading the OS. I have a site that has 1 gig on terminal with 8-10 users & it just isn't enough & they use btrieve. If you have 5-6 terminal users trying to run client sessions & the server trying to manage the SQL processes, I can see where you might have performance degradation. On report performance, I thought you meant crystal, but if you are referring to the cobol macola reports, I have seen those run slower on sql than btrieve. Again, file validations & cleaning/purging big files will help this problem.

 

[Lorain]

Hi Scott, I will pass on the advice of multiple processors. We can also have some users do work without remote logins today and see how it goes. The reports & processes are standard macola reports in various modules. We are using ODBC for Crystal connections. These users have just upgraded from DOS ver. 6 and they are quick to think the system is "hung" so they 'Ctrl Alt Del' a lot. I have stayed on the phone with them and reports can take a very long time to finally come back. They have a new problem yesterday-can't print to screen. This problem does really lock up macola. I have removed all the tmp and print files from data dir, some modules were at 99 reports. The workstation paths are fine and the users have full rights to the data directories.

Thanks for the feedback.
Lorain
lorainst@cs.com

 

[stravis]

Standard Macola reports can and will take a bit longer to return results from Macola than under Btrieve. This is because most of these reports were written for a transactional database engine, not for a relational database engine like MS SQL. You can greatly improve the performance of these reports be taking the TS users off the SQL Server and make sure that the workstations generating the reports have been well fed over the years and have grown up to be big, strong, and fast computers.

Scott Travis
infoSpring, LLC.

 

[Lorain]

We are working on a plan to remove TS users off the SQL server and we just bought new computers for all users, that is why I was so surprised to see the slow results on processing and reporting. Thanks. Lorraine

 

[johnCronin]

I would switch to the oledb driver for the Crystal reports

 

[stravis]

The oledb driver would definitely be faster for Crystal, but only marginally so. You will see a speed increase and it will also ease deployment of Crystal Reports to user PCs. I would not suggest making the effort if the need does not exist.

Scott

 

[MacolaHelp]

Just looking at the hardware & platforms docs today @ macola for another client, I see that macola specifically states NOT to have terminal services running for client access on the SQL box. The print to screen thing may be solved by downloading the 01232004 print update from downloads, initializing reptpass & printdft files. If you initialize printdft, then users must reselect their printers the next time they run that job, but it allows a clean reconnect to the printer.

At one site recently, I had a print to screen problem on 1 win2k WS, novell 5.1 after upgrading to 7.6.200. Couldn't fix it no matter what. Got a new xp WS, could print to screen. User's profile changed on the domain in preparation to migrate to sql. Print to screen broke again. Updated to sql macola on win2003 server, still no print to screen on this lone WS. Reinstalled the OS & apps on this machine, it works fine now. The user may be doing something odd on the WS w/screen saver, weather bug, etc. The user also runs an older version of lotus, which I have heard rumors causes problems. It also sounds like you have data issues if there are 99 rpt files & tmp files. Once you get TS users off, I'd do a major cleanup.