Issue resolution

Top  Previous  Next

 

 

 

 

In this section are some issues and possible solutions

 

 

Issue: Errors resulting from ole objects not being registered.

Stratford recommends that you have 'administrator' privileges when the program is first installed as well as when updates are installed. You must have 'administrator' privileges when you run the program the first time after the original installation and after an update. The reason for this is that 'ole' objects must be registered with the operating system. It is a requirement of the Windows operating system. We see no reason for the requirement but it is something we must live with as long as we use an operating system designed by Microsoft.

 

Solutions:

1. Make sure you have administrative privileges before you log in. You should be able to check your user privileges. Note this is the Microsoft operating system user and has nothing to do with the Stratford program.

2. If you log in and still have problems it could be that a required service is not active in your operating system. Do the following: (assume Windows XP Pro, SP2)

Click Start, Settings, Control panel, Administrative Tools, Services (not Component Services). This will open a new dialog. Scroll down the list on the right side to 'Security Accounts Manager' (you may only see 'Security Accounts...') If the status is not Started and/or the 'Startup Type' is not Automatic - change them.

3. Reinstall the update. Note this still may not work this time (it will work next time) because the software may 'think' you have already installed the update and will be unable to re-register the components. You may request a later version/build from Stratford. There is another possible solution that we do not recommend unless you have a current, known valid, backup of all your data and you have the ability to recover from that backup. In addition you should be 'computer literate' and be comfortable with the windows explorer functions: copying, deleting and moving files, etc. Find and rename a file named ssiuser.ini in your computer user directory: (example :C:\Stratford\ssiwin\4\Computer\xyz\ssiUser.ini - where xyz is the name of the computer with the problem). Consider yourself forewarned that this is not a 'routine procedure' and we absolutely do not recommend that it should be done without first making sure that you know what you are doing. This file has some settings that could be lost. These settings are not part of the software so you should not notice any significant problems. Remember that Stratford does not have a copy of your data and if you delete/rename the wrong file, we may not be able to help you recover. Also, your software maintenance does not cover any services that might be required and you will be charged for labor and materials whether or not we are successful. If you are able to rename this file successfully, you should be able to log in and the software will try to register all the ole components. For those expert users: you can simply rename this file to something like ssiUser.sav, log in one time so the 'ole' components are registered, log off, rename the file back to ssiUser.ini.

 

Issue: corrupt files (data tables)

Description: different errors that indicate that the software cannot access the data in one or more tables.

1. Not a database file (Error number 15)

2. Table <name> has become corrupted (Error number 2091)

3. Memo file is missing/invalid (Error number 41)

 

Cause:

1. Most common is power loss, turning off power, resetting the computer while the program is running.

2. Less common are many things such as hardware failure, etc.

 

You can have a bad area on your hard drive.

 

Solutions:

1. Most solutions are just 'patchwork' at best. If you are lucky you may not lose any information. This is one of the primary reasons for making a backup at least daily or even more often if you are doing a very large amount of data entry such as converting to Stratford from a different software product.

2. chkdsk.  Go to a dos prompt and type CHKDSK C: /R  << you must substitute the disk location of the data files if they are not on C:. If you do try to run chkdsk on drive C: it will not work until you reset the computer. You will get a warning message to that effect.

3. de fragment your hard drive. This is a good idea for routine maintenance. It will make your computer seem to run faster. You can find this under 'Start | Programs | Accessories | System tools'.

4. Consider using a UPS on the computer that has the data files. Even better - on all computers on your network. These are relatively inexpensive now at Costco, Walmart and other discount chains.

 

Whatever you decide to do, you must try to get a good backup first. We recommend backing up on CD or DVD as this is a near-permanent media and can be read by almost any computer. We do not recommend tape or copying to another hard drive. Backing up to the same hard drive is not a backup at all - it is a waste of time. Backing up to CD/DVD can be slow if you have a lot of data. An acceptable compromise might be: copy to another computer on the network and then backup that other computer to CD/DVD.

 

If you are not able to recover your data and you have a recent backup, Stratford may be able to help if you subscribe to software support on a long-term basis. This can be a very labor intensive endeavor that requires our most technical employee(s) and may be unsuccessful so we will not do this for those clients who do not have a long term support agreement. Consider a long term support agreement with a credit card on file.

 

Nothing you do is a substitute for making a frequent backup on reliable media that can be restored on most computers. We have had clients in the past who have been making frequent backups but there is no data on the media. Consider doing a test recovery to prove that you really do have a backup. If you make a backup to CD/DVD, most programs can be set to verify the data after writing the media. This manual is full of statements about making backups. Unfortunately it seems that a majority of people have to suffer through a disaster at least one time before they get the message. They think a backup is too much trouble or costs too much. You can get cheap CDs / DVDs that are 16X or better so they will backup a very large amount of data quickly. A daily backup for a 5 day work week takes about 250 CDs for one year of data entry which can be stored in a very small amount of space. It is a real treat for us to help a client who has many frequent backups. If you do not have a backup you can expect to pay many, many times the cost of a backup in labor and lost income. It is also very bad for the moral for the office staff. Don't let it happen to you.

 

As a rule, we do not like to recommend a specific product. We have had clients who lost a lot of data who said something like - if Stratford had recommended a specific way to backup the data, they would have done it. Well, this manual is full of statements about making backups. It takes up space in every one of our monthly newsletters. Check it out. Our web site has monthly newsletters back to the mid 1990's. Try to find one without a backup recommendation. For specifics, here is one we are using as of this writing: WinZip version 12.1. This program is so cheap for what it does that you have absolutely no excuse for not making a frequent backup. This program is less than $50 and will compress your data and backup onto CD or DVD. If you have too much data for one CD, it will 'span' several CDs. It is a great program and we use it every day.

 


 

Here is a story that was posted on a software developer newsgroup:

I "forced" an associate in Seattle to let me install a UPS and external HDD for file imaging and backup purposes on his Server last August.  He whined about the cost, but I told him he either takes measures to protect himself, or he could find someone else to provide him the commercial services I was about to set up for him. He wondered why I was being so harsh, and I told him that not if, but when, he had a problem I knew he would end up calling me.  And I do not have the spare time to try to get a machine in Seattle back up from scratch, or to waste my time with anyone not willing to prevent problems when it is so inexpensive to do so.  I also told him if he was really lucky he would never have to thank me for forcing his hand, and if even luckier he would eventually end up thanking me.

 

He rolled over, and I installed the equipment and software, blew an initial Drive Image (www.R-TT.com, they have R_DriveImage for $45, works on Windows Server platforms), and set up the nightly file backups (SyncBack).  Two days ago their Server hard drive crashed mid-day.  Who do you think they called?  Me, the one who forced the backups and UPS on them <g>...  Within 2 hours, remotely guiding their non-IT office clerk, I have them up and running with a new hard drive.  And over the next few hours I had restored all their data files (about 200 Gb, it took a while) current through the previous night's backup.  I could not help myself, so I got transferred to my associate and asked, "Aren't you glad you listened to me last year?"  He confessed he recognized the value of the investment, and said he never did dwell on the cost after I had installed the equipment and software - he had gotten over it.  Had he not been protected he would have had to send the old drive out to a data recovery lab, maybe pay a few thousand $ IF they could recover data, rebuild the Server O/S, etc.  Had no data been recoverable he would to have shut his doors, as all of his client info, billing, active projects data, etc., was on that Server.  Less than $500 invested last year saved their business.  I have no idea how much grief the UPS saved them over the past year with power related issues, but I bet they had no power related problems on the Server...

 


 

Here is a table of things to check if you have possible file corruption problems:

Possible cause

Area

Action

Corrupt data in the dbf's that corrupts the indexes.

Data

Inspect the indexed fields for causal or collateral corruption.

GPFs on workstations causing havoc with server-side data

Environment

Inquire about workstation GPFs.

A legacy FP 2.6 app somewhere,
or perhaps. Excel, Access applications accessing or modifying data?

Environment

Inspect all applications connecting directly or through ODBC.

Virus: several client systems had a virus that caused index corruption but didn't seem to display any other symptoms

Environment

Scan for viruses everywhere

Video or printer driver conflicts in memory.

Hardware

Audit all video and printer drivers, and get and install the latest versions from manufacturer's websites.

Hardware not Windows-Approved

Hardware

Make sure that machines running Windows have tested and approved components.

Bad memory chips.

Hardware

Run hardware diagnostics on all machines.

A faulty NIC (just one) can cause index corruption.

Hardware

Run NIC and network diagnostics from all machines. Network faults could be the cause, but have to be traced systematically and physically for NIC as well as cable faults.

Bad sectors on the disk where
temp files are being written.

Hardware

Chkdsk and defrag the disk drives

Overloaded networks. move to a switch with Cat5/6 - 1 gig or faster.

Network

Ask LAN administrator to comment on and measure the peak network loading.

Another thing to rule out (though I don't see how this could corrupt indexes) is that the temporary directories for the clients exist, write privileges exist and there's enough room to write this temporary information.

Network

Check for rights, disk space on
temporary directories

Since this is a "mixed" environment, is there a NET.CFG? If so, it should probably have show dots = on, to handle relative directory references. Not sure what this could do to an index problem, unless we're talking about some tables that are not in the same directory as their DBC, but it could happen!

Network

Check NET.CFG for SHOW DOTS=

 

 

Issue: 'The program runs slowly' .

Description:

The Stratford program runs fine on the server but the workstations are slow.

 

Response:

Programs (the software) do not run fast or slowly. They run at the speed of the hardware. Hardware includes everything you can touch/see: Server, Cabling, Network switches/hubs, workstations, modems, etc.

 

Here are some things to check:

 

1. The amount of memory is number 1. This is critical on the server, but important on the workstation(s) as well. If you are using the Windows version of our program, we recommend 1 gb memory, 2gb is better, 4gb is better still and may be necessary if you are unlucky enough to have Vista as your operating system. The dos program may not require as much memory, but the more you have, the faster the program will run. CPU speed is not as important as memory.

2. Defragment the server and the workstation disks is number 2. The workstation gets a copy of the data and programs from the server and stores it in the Windows 'swap file' (depending on how much memory you have on each workstation) while you are logged in.

3. Virus programs can make a big difference. We recommend Avast and PC Tools. we use them here at Stratford.

4. Reorganize your data. If you do a lot of data entry, your data files are constantly being 'disorganized'. The data for a single patient can be all over the hard drive. Reorganizing your data, sorts the data and re-creates all the indexes. The software can access the data you want faster when all of a patient's data is in contiguous records. This is important for large database programs like Stratford. You should do a backup at least daily and a reorganization at least weekly or monthly depending on the amount of data entry you do.

5. A dedicated server will always result in a faster response time for the 'slave' workstations on a network. When you use the server for a workstation, it hogs the memory and response time from the attached workstations. After checking the items above, try using the workstations while no one is working on the server computer - see if it makes a significant difference.

6. Creating reports, statements, and insurance claims causes a significant drag on the system and will always result in a slow system. Data entry generally does not put a lot of drag on the system. We have users with 20+ simultaneous users with acceptable response time. Try running non-data entry programs at lunch time or other times when people are not looking up patients, data entry, etc. Running reports, statements, insurance claims on the server will kill the network performance.

7. Although this is rarely the problem, if you have several workstations it can be significant - Your network cabling is the most common cause of speed problems. If your hub/switch is capable of 100mbs, and you have 4 workstations connected to a server, then the speed is divided by 4: Each workstation can only connect to the server 1/4 of the time if all are active. Upgrading to a 1gbs switch would allow all 4 workstations to connect at 100mbs, assuming that the server has a 1gbs network interface card (NIC) and the workstations have a 100mbs NIC. If all computers have a 1gbs NIC then the speed would be even faster.

8. If you have many workstations, we find that Windows terminal server may give the best response time. It allows you to use cheaper, older computers as a workstation with minimal memory and CPU requirements for those workstations. The terminal server should be as powerful as you can afford with the maximum memory that the hardware will support.

9. Windows has this crazy thing called the registry. This was another one of the many Windows bad ideas. Microsoft is finally starting to move away from this nonsense with Win7. This is the reason you have to 'register' ole components. A really bad idea we think. It is nothing but trouble and the good things about it (very few) do not even begin to outweigh the bad things. There is a free utility named Ccleaner (yes there are 2 C's in the name). This utility can help clean up the registry and temp files and many other good things. Be sure to de fragment your hard drive after running it.

 

There are probably other things that can cause a slow network. If your hardware person has testing equipment to test the network connections, you should have that test done first. We find that the cabling is the most common cause of a slow network.