Advantage XBase Server and Fortress are two server-based products that are designed to increase speed across network pathways. Here's what Phil Barnett had to say about the Advantage product:
"In Clipper, as we know it today, the index access requires many file accesses to retrieve the record pointer for the data we want to access. If I remember correctly, it takes around 20 packets to just get to the record, and 21 sends the request, and 22 returns the data packet to you.
"Contrast that with Advantage, where there is one packet to request the data, and a second packet to return the selected record. The actual index seeking occurs at the server level at bus speeds.
"Since there is a 10:1 reduction of network packets, you can expect a profound increase in access speed."
(Answer supplied by InSystems Technologies, 18 January 1995)
//BADCACHE should be used whenever something in your system will change the EMS page frame without notice. In plain English, any TSR, device driver, or similar device that changes the page frame. This includes the EMS version of the NetWare Shell for DOS (EMSNETx), the NetWare DOS Requester (if you use the /ME parameter), the Microsoft LAN Manager redirector (if "/LIM" appears in LANMAN.INI), the IBM LAN Server client (if "/EMS" appears in DOSLAN.INI), the EMS version of HyperDisk (HYPERDKE), etc.
On the other hand, RUNning a program that uses EMS, such as WordPerfect, should not be a problem.
The problem comes when I/O calls affect EMS and the I/O device doesn't restore the EMS page frame to its previous configuration.
If performance is a consideration, you should avoid caches and LAN drivers that use EMS, since they are not only slightly slower than conventional memory based drivers, but they really put the brakes on Clipper.
(Answer supplied by William David Belew, 7 February 1995.)
Try Blinker's RUN replacement, SWPRUNCMD().
Add the line BLINKER EXECUTABLE EXTENDED (protected mode) or BLINKER EXECUTABLE DUAL (chooses real or protected mode at run time). Note that C, assembly, and 3rd party libraries must be protected mode compatible.
(Answer supplied by Phill Terry, 10 February 1995.)
The first record in a database (.dbf) header is 32 bytes in length and contains information describing the file as follows:
Table: File description record
------------------------------------------------------------------
Offset Format Contents
------------------------------------------------------------------
0 03 or 083h Signature Byte:
03h - (.dbf) with no memo (.dbt) file
083h- (.dbf) with memo (.dbt) file
1 Year Last update year without century
2 01 to 12 Month of last update
3 01 to 31 Day of last update
4-7 Long Number of records
8-9 Word Location in file where data begins
(START)
10-11 Word Record length (field sizes plus 1)
12-31 N/A Reserved
------------------------------------------------------------------
Note: When a database file is created, bytes 12 thru 31 are NUL filled. Once a database (.dbf) file exists, care must be taken NOT to change reserved values since dBASE III PLUS uses these values where the Clipper DBFNTX/DBFNDX database drivers do not.
Note, also, that the signature byte in dBASE-made .dbf files is different ... I can't remember the value of that byte, but it's NOT 03h or 83h ....
Also, you can look up the format yourself in:
Chapter 11 Clipper Programmer Guide Rick Spence (the Lance A. Leventhal Data Based Advisor Series) LCCC No. 90-53257 Microtrend Books Slawson Communications, Inc 165 Vallecitos de Oro San Marcos, CA 92069
You need a program called (surprise!) LIB.EXE. You can download a copy from
ftp://ftp.qbss.co.uk/dos/misc/MSLIB.EXE. Run lib /? to
get help on using the tool.
(Answer supplied by Ian Day, 14 February 1995.)
When repositioning a TBrowse, you may have found the right record but the :refreshall() and :stabilize() calls move the record pointer elsewhere.
This is a common problem. When you signal a RefreshAll() the tbrowse internal skips back to the first visible record, you can stop this happening by forcing the tbrowse row indicator to the top of the browse, but you must do this before you issue a RefreshAll().
So, something that may work for you would be:
dbSeek(cSomething)
oBrowse:RowPos := 1 // So it doesn't need to skip back
oBrowse:RefreshAll()
oBrowse:ForceStable()
For a good article on this, check out Clipper Advisor, March/April 1994, "Using Netware TTS: The Real Story".
First of all, it's fine for single-user apps.
For multi-user apps, problems arise because of a mismatch between Clipper's locking scheme and TTS.
In DBFs, Clipper's default record locking is to lock byte (1 billion + RECNO()) from the beginning of the file. TTS will actually lock the data being written to. So another user trying to go thru the record will get "access denied".
In indexes, you may get TTS locks at several places in the index file for a single field modification. When the user tries to browse past one of the locked places, you may get an "access denied" or a "corrupted index" error.
There are other problems too. I would really advise reading the article before trying TTS on data and index files for a multi-user Clipper application.
The good news for you is that you can easily turn off TTS for just the files used by the Clipper apps - use FLAG to get rid of the "T" attribute for the relevant files.