Slow Opening and Saving Reports on Network
If File-Open is slow on a network, it may be because you are running Win 2000 or XP on a workstation. These operating systems communicate very slowly with a Win 2000 server and even slower with a NT server. In such cases, you may need to archive your reports by year in TRADATA\DATA so that there will not be as many reports in the directory you are trying to open. This in turn may require that you rebuild the index. Alternatively, you may try using the File–Index rather than File–Open to open the reports. But the speed problem will still exist when you save the reports.
The most probable solution however is probably to be found in the Microsoft section below. The OS system is probably the culprit and affects our software because we have a lot of files in the directory on the server, and the OS does a poor job of communicating when there are a lot of files in a directory. Microsoft has acknowledge this problem is their OS, but a solution preformed at their OS level is not something with which we assist. Rather, since it involves a registry tweak, it is something you should have your on-site technician do. We provide the Microsoft information below for your technician’s consideration.
You should also make certain that TRA and TRAPRIV are set for local operation in TRA.INI (and that TRAPRIV is kept relative clean with AIFILES).
In order to make sure there is nothing on the system or server, causing the slow down,
Microsoft has acknowledged this problem, and you may have your technician consider the following information. Again, this information is provided for your technician’s consideration. Increasing the size of the buffer will make XP and W2000 Servers run more palatably. Running REGEDIT will allow you to change the buffer size. This is not something we support in our tech support, nor is it something we would advise you to do yourself. Your on-site technician can try the MS suggestions and take the appropriate safe guards such as backing up the registery.
Suggested solution to the difference in the way Microsoft XP and Windows 2000 handle the FAT tables (as opposed to Windows 9x). Here is an excerpt from supplied by a tech in the field dealing with our software. If you do a GOOGLE search on SizReqBuf, you will find additional information from Microsoft sites. See two samples below the following details.
Default value is 4096 with a range of 0-65565 Decimal. Setting to 29128 and it seems to be a good balance between 2000/xp machines and 95/98 machines. Do the following on NT4/Win2k servers with the share folder with many files (e.g., \\server\photomgr\jpg or \\server\tradata\data:
1. Locate and click the following key in the registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
2. On the Edit menu, click Add Value, and then add the following registry value:
To work around this issue, use the following steps to edit the SizReqBuf registery value:
Data type: REG_DWORD
Value data: 14596
Data : 512 - 65536 (bytes in decimal) Default : 4096 NOTE : A SizReqBuf value setting of 14596 works well in most standard Ethernet environments. However, the best value to use in a given environment depends on the specific configuration of that environment. The minimum SizReqBuf value setting is 512 , the maximum SizReqBuf value setting is 65536 , and the default SizReqBuf value setting is 4096.
MS: Slow File Write from Windows 2000 to Windows NT 4.0 Server (Q279282)
Data Type: DWORD Value
After you make this change, the performance of the write process is approximately the same as a read operation between the two computers. Note that the SizReqBuf value controls the buffer size for CORE SMB requests. Setting it to 64 KB has approximately the same effect as Large Write support, which uses 60-KB buffers.
XP Slow Even on Standalones
It has also been noted that when you upgrade a Win 98 to a XP, it retains its FAT32 subsystem, which is 50% slower than installing XP from scratch on a new system with a NTFS subsystem. So a new machine running XP on NTFS may be expected to run 50%, with all things else being equal. To check which file system you are using, open Windows Explorer. Right click on the C drive and left click Properties. The file system will either say Fat32 or NTFS. Other factors would include making sure you have plenty of ram (such as 512mb) and a fast hard drive (such as 7200rpm). One customer stated that Appraise-It would slow down whenever sending or receiving faxes, but when they plugged the fax machine into a different outlet other than that used by the power strip, Appraise-It functioned at normal speed. So adequate power supply and reduced background applications would also be considerations.
and 2000 use a VFAT system (Virtual File Allocation Table) as opposed to
standard FAT that 9X uses. There are several differences in how the two tables
are defined (mostly in information stores, name length and OS compatibility)
The VFAT file system is a Linux-based file system that is compatible with
Windows 95 and Windows NT long filenames on the FAT file system Windows 95 and
Windows NT support VFAT. Technically, VFAT is not a new File System. It uses
the same directory structure, format, and partition type as ordinary FAT. VFAT
is simply a way to store more information in the FAT directory. The most
important feature of VFAT is the ability to store long file names. Since it is
built on ordinary FAT, each file has to have an 8 character name and 3
character extension. However, VFAT then allocates additional directory blocks
to hold a longer file name. Programs running in DOS, OS/2, and Linux (and old
16-bit Windows programs) will not see the longer file name. Only WIN32 programs
running in NT, 2000, XP or Windows 95 can make use of the longer name. Because
VFAT uses the old FAT directory to add some unusual new entries, the VFAT
additions can be damaged if the disk is manipulated by a DOS or OS/2 disk
utility that does not understand the new structure. Even a simple
The following speculative information for NETBEUI is supplied with skepticism.
We have had customers using Appraise-It on a P2P network who changed the network protocol to NETBEUI file sharing and then claim that the reports would then save in normal time span rather than taking one to two minutes. Admittedly, TCP\IP is generally the preferred protocol rather than NETBEUI for true client-sever networks (or P2P) in which you are accessing the Internet. But NETBEUI is faster for file sharing. Ideally then, you could set up your network to use both protocols. Use NETBEUI for the file sharing (and TCP\IP for the internet access) so that when Appraise-It saves the file it will be using the NETBEUI protocol.
If you still have problems using NETBEUI (or TCP\IP), then have your technician test the hardware (i.e., the hub, wiring, cards) to make certain they are still functioning at full capacity. Of course, ideally you would have a dedicated client server rather than P2P. If your technician will do a search in google.com for “slow network performance,” he will find numerous articles pertaining to this problem. But we have found no article at this time that resolves the problem for our software and would thus suggest you call Microsoft if a solution is not attainable with NETBEUI protocol.
A windows 98 workstation will communicate normally across the network, but the NT, 2000, and XP communicate very slowly with our software. The OS makes the difference so discussing this with MS would be advised. The problem may be due in part to the fact that our application is 16bit and has thousands of reports in the data directory. Emulation mode may help with the 16bit application limitation and archiving with the number of reports in the data directory. See our faxes concerning emulation and archiving.
Other suggestions from the field include: not using NOVELL, using ntfs rather than something like fat or fat32 for the hard disk file structure, be certain you have 100 mbit connectivity throughout the network.