Monday, January 26, 2009

Internal Errors

This document was printed from the Norton Guide: `Clipper 5.00a -
Internal Errors  V1.04' by  Terry McConnell. Though dated, I have found
it to be extremely useful. The Clipper 5.3 NG on runtime errors may contain
updates on these internal errors.

By the way, I have not been able to reach Terry McConnell to enquire on the
latest version of his document. Please e-mail me If you have
his latest e-mail address.

Internal Errors

Internal Error #0 through #100 These messages are the same for Summer '87 and Clipper 5.0. Check out IERROR.TXT in LIB 0 for complete, official explanations from Nantucket. Internal Error #332 (#109665) User reported bug to Nantucket that when you fill array with a value and then change this value to NIL or "" (presumably, a value which, internally, takes less space), and refill this array the run can fail with an internal error 332 depending on the length of the new values. Internal Error #333, ARRAY(0) & STATICS$(0) (#99608) Appears during creation of multi-dim array structures or use of macros? Very Mysterious & Elusive. Sometimes disappears on it's own. Try shuffling the code around. (#100777) Error may be generated when the system cannot find enough contiguous memory for a big array or large variable. Declaring: STATIC aJunk[1,2,3,4,5,6,7,8,9,10] can bomb. Seems to have something to do with STATIC declarations. (#112790) This error occurs in DBU when it attempts to read long directories into memory via the DIRECTORY() function. Again, this is the same problem. (#118666) If you are being plagued by Internal Error 333, you may want ~ to try this fix from Jo French [74730,1751]. Instead of using methods to declare your array assigning an initial size, like: LOCAL aBig[4000,8], try this: LOCAL aBig := {} FOR nX := 1 TO 4000 AADD(aBig, {}); ASIZE(aBig[nX],8) NEXT nX See Also: "Internal Error #442" Internal Error #415 (#101160) Error opening dynamic file. Occurs when you compile a file and link with first object module name longer than 8 characters. This is a problem with RTLINK.EXE, not with CLIPPER.EXE. The problem involves specifying an object filename longer than 8 characters. The extra characters are ignored during file access, so the link works, but the EXE has the extra characters in its reference to itself for VMM and dynamic code swapping. When you run the application, and it attempts to load another part of itself, it can't because the internal file name is invalid. Solution: Don't use longer than 8 characters for filename. () When running on a PC-AT 3270 microcomputer with PC DOS v3.30 & v3.20 ~ loaded, and the IBM 3270 PC Control Program Level 3.00 loaded, Clipper bombed with this error message. Once the IBM 3270 PC Control Program was removed from memory, this error message disappeared. Internal Error #416 (#96017) Unable to access .exe for next dynamic page of code. () This description seems very consistent with every description of this error I've seen. For some reason, your .EXE is no longer available to read data from itself. During the time that a Clipper application runs, it swaps information from the EXE file to memory. If the EXE is no longer available to read, then the program will bomb with this error. (#115578) A user gets the message frequently on a Novell Network. One ~ suggestion from Nantucket Tech Support asked if the same .EXE existed in another directory in the search path. This may cause this error. (#115909) Kurt Schaldenbrand [72137,2703] suggests that this error is ~ related in some way to expanded memory: "When a customer adds expanded memory, occurrences of both 416 and 5320 go away." See Also: "Internal Error #5320" Internal Error #442, STATICS$(0) () This error can be produced by writing a program that declares a huge STATIC array much like the example shown in the Internal Error #333 listing. It can also be produced using a LOCAL declaration. In this case, "STATICS$ (0)" is replaced by function name and line number. See Also: "Internal Error #333" Internal Error #521 (#96396) Occurred during the macro expansion of an array in a REPLACE...WITH...NEXT command. It was unclear from the example provided if the error was caused when a 'M->' preceded the array element, or when it did not. There are indications that the message is sporadic and hard to duplicate. (#119988) IE #521 occurred in a replace to a memo field. (Note that this ~ thread refers to the error as #512, but in the end it was #521 that the user was getting) The error disappeared the next day, no resolution or workaround was offered. Internal Error #612 (#94798), (#94656), Cause: Submitting to EVAL() a first parameter whose type is not codeblock. Most common cause is linking in old ERRORSYS.OBJ files from Summer '87 applications - even if recompiled with 5.0. (#101142) Occurred on second access to a database w/ Lastrec() then Recno() - Perhaps memory problem? -- not consistent with other examples of this error. () In a custom ERRORSYS procedure: Not setting ERRORBLOCK() or committing an error prior to setting ERRORBLOCK() will force this error. Internal Error #650 (#95972) Problem occurred during block evaluation from within a custom error handler? A message preceding the error indicated that the program had run out of stack space: "Processor Stack Overflow." () I got this error to occur by specifying an undefined ERRORBLOCK(). In other words, the function call in the codeblock that I passed to ERRORBLOCK() had a symbol reference in it that was not linked to the program. .RTLink generated an "unresolved externals" message and indicated that "EXE may not execute properly." I suspect, however, that this error has nothing at all to do with ERRORBLOCK()s in general, but, instead, has something to do with the evaluation of a NIL or undefined codeblock. (#111301) This thread seemed to indicate that 650's real nature has something to do with a stack overflow. Increasing stack space may help to remedy the situation. Checking your code for recursion may help as well (especially if you hadn't intended that there be any recursion). (#113260) This error occurred for one user in a 500 line test program with some ASM modules linked in (though they did not appear to be the problem). After this user changed a few static variable names, 650 began appearing in _APPINIT(0) (a Clipper internal). (#117157) One user got this error when he named a program ACHOICE.PRG ~ and compiled it to ACHOICE.EXE. There can only be one symbol name for a procedure or a function. If you have an ACHOICE.prg and you are not compiling with the /n switch, any calls to ACHOICE() will cause the assumed procedure ACHOICE to be executed. This results in recursion and an eventual 650 stack overflow. Remember, functions and procedures are essentially the same. Internal Error #666 (#98491) An invalid string was passed to SETCOLOR(). () I was unable to reproduce this bug with some pretty wild SETCOLOR() strings. Some folks believe that it is not really a SETCOLOR() problem and that, instead, it is a memory problem in SETCOLOR(). According to other testers, macroed variables are more likely to produce the error of the beast. Who really knows the true nature of Hell (... better than Basil Hosmer and Dante') ? :) (Mail) Pat Cassidy [76605,2365] provided me with these two wonderful hair raising bits of code. They both faithfully produce the 666 error on my machine and his. (pun intended) ************************************************************ * Program 1 ************************************************************ line := 0 set color to ("$$$$$$$$$$$") ; ? ++line //1 x := setcolor() ; ? ++line //2 ? "Setcolor returns ", x ; ? ++line //3 set color to &x ; ? ++line //4 z := "@@@@@@@@@@@@@" ; ? ++line //5 set color to &z ; ? ++line //6 set color to "z+/z/t/m/q" ; ? ++line //7 ? setcolor() ; ? ++line //8 - last line executed ok m = "z+/z/t+/m/q" ; ? ++line //9 - setcolor(0) error here?? setcolor(m) ; ? ++line //10 set color to &m ; ? ++line //11 ? setcolor() ; ? ++line //12 set color to "w/n,w/n,w/n,w/n,w/n,w/n" setcolor("W/n,w/n,w,n,w/n/w/n,w/n,w/n") ************************************************************ * Program 2 ************************************************************ line := 0 set color to ("w/n,w/n") ; ? ++line // print "1" x := setcolor() ; ? ++line // print "2" ? "Setcolor returns ", x ; ? ++line // and "3" set color to &x ; ? ++line //4 z := "w/n,w/n" ; ? ++line //5 set color to &z ; ? ++line //6 set color to "w/n" ; ? ++line //7 ? setcolor() ; ? ++line //8 m = "w/n,w/n" ; ? ++line //9 setcolor(m) ; ? ++line //10 set color to &m ; ? ++line //11 - ok so far(prints 11) ? setcolor() ; ? ++line //12 - never gets here set color to "w/n,w/n,w/n,w/n,w/n,w/n" setcolor("W/n,w/n,w,n,w/n/w/n,w/n,w/n") Internal Error #773, (#112934) User indicated that the error would occur with a bunch of junk on the screen -- which indicated to him that it may be some sort of "memory trashed" error. The only reports of this error are very sketchy. This same user later indicated that the program involves a large chunk of Microsoft C 5.1 code called from Clipper 5.0. (#112958) One user said that after getting an internal error 416, and executing the program with //info, he got 773. (#116899) BJ Walsh [71121,3013] found that this error was caused by his ~ attempts to free pointers from C that didn't belong to his program. See Also: "Internal Error #416" Internal Error #777, (b)OPENDB (0) (#94779) This appeared to occur concurrently with memory problems, and after a RUN command. Internal Error #993 (#96477) An example of this error occurred during an attempt to macro compile a local in a block expression (INDEX..ON). First the "Error BASE/1065 Argument error: &" occurred. Then three copies of this error message (#993) were output. The message "Aborted during termination" also accompanied this error message before the application came to a screeching halt in the land of the C prompt. () My experiences with this message occur in a custom error handler. After receiving an error message during a stabilize of a tbrowse, the internal error 993 is generated as I display an array containing callstack information. I'm not sure what the correlation might be -- except for the fact that both occurred within an error handler. (#110724) The following function was reported to crash with an internal error 993 (Don Kiely 72657,475): FUNCTION OpenFiles() FIELD Number IN JOBS USE COMPANY INDEX COMPANYN,COMPANYC NEW USE JOBINFO INDEX JOBINFON NEW USE JOBS INDEX JOBSN,JOBSC NEW SET RELATION TO Number INTO JOBINFO ADDITIVE USE PEOPLE INDEX PEOPLEN,PEOPLEC NEW // Dies here. RETURN NIL Don said that when the error occurs, the call stack looks something like this (without using any special error handler): OPENFILES __DBSETIND (b)ERRORSYS (b)ERRORSYS I was unable to re-create this occurrence by using similar databases. (#122336) Laurence Wieland [71141,1411] suggests that this error is ~ generated purely on the basis of recursion: generating an error within an error handler, for instance. I wonder if there could be some problem with the callstack that causes the tail to point to the head, causing the callstack problem I outlined above ... (?) (#115799) Carl Byington [74040,1156] provided this information: ~ "Internal error 993 may be generated by the error handler trying to do a nested read (for an error that was caused by a valid or when clause) without the extra assignment statement that is required for any nested read to work correctly." Internal Error #999 (#110250) It has to do with calling a function via a macro that was not linked in. Look for a function that you are calling via a macro like: nVar := "UDF()" RetVal := &nVar ... However, I was unable to reproduce this error using this example. (Mail) Forest Belt [70054,3664] received IE #999 when linking a Summer ~ '87 UDF into a home built .LIB file with a group of .ASM and 5.0 UDFs. I was able to verify this by writing a program that called a S87 compiled function. Rtlink will warn you that you are attempting to link a S87 module with a 5.0 one, and will show "_VSTD" and "SUMMER87" as undefined symbols. Apparently, Clipper is attempting to call one of these functions when it dies with the IE #999. Internal Error #1104, __DBARRANG(0) (#102789) Occurred during a SORT..TO on an 8086 machine & expanded memory. Other reported cases show it occurring on a COPY command and not in __DBARRANG(). Internal Error #1110, __DBCREATI(0) (#111278) This error was encountered during creation of an index file in a maintenance program. Appending to this same file caused an internal error 416. The user reported that this problem went away when he copied his program to another directory; same hard drive, free space, files, and RAM. (#115248) Internal error 1110 may mean "zero length index key." Check ~ your index key for TRIM() functions or other functions that may evaluate to a variable or zero length index key for different records. The Clipper reference manual has a discussion on how to workaround zero-length index keys on page 4-56. See Also: "Internal Error #416" Internal Error #1210, __DBPACK(0), __DBSKIP(0) Record not found in index. It should only occur if the database is updated without the index being open. Recreating the index and re-running may clear it up. (See Also Richard Thompson's BADPAC.ZIP or Fernando Villar's IE1210.COM in the Nanforum libraries for examples) (#95089) This scenario says to make a small database, and then make 2 indexes, one indexed on a large field and the other a small field). Make sure the order in the SET INDEX command is large key then small key. Performing consecutive GO BOTTOM; DELETE; PACK will crash to internal error #1210. I was unable to reproduce this error by using this method. My key was 30 characters for the large index, 1 for the small, and I had 300 records in my test database. (#110430) This indicates that 1210 can occur when two machines update the same record at approximately the same time using an rlock(), commit, unlock sequence. (#112069) The following code fragment goes through an entire table replacing the FILTER field. There are three indexes open when the order is set to 0 before the loop. Part of the way through the table the error INTERNAL ERROR 1210 __DBSKIP(0) occurs. set order to 0 go top do while !eof() @ 0,0 say "Company"+profit->comp_code lockrec() profit->filter := if(profit->contract Internal Error #1242 (#96613) When using a SET RELATION and using an alias field in an INDEX statement the INDEX does not work correctly. If the program is executed by itself (not under debugger) it creates a variable not found error. If the program is executed under the debugger it creates an Internal Error 1242. At the suggestion of a Nantucket support person, the programmer added a FIELD statement - this eliminated the error message when executed by itself, but the program did not work properly - it just ended either after or during the INDEX. When executed under the debugger it created an Internal Error 1242. According to Nantucket support personnel, "indexing on a field in another work area does not always work properly," and could cause this error. (#109860) Information presented by another user indicates that this error may not be in indexing, but in the debugger -- or in the debug code placed in the object by Clipper. () After testing code provided by Peter Bilka [73417,1316]: // test.prg use child index on cname to childn select 1 use child set index to childn select 2 use parent set relation to cname into child go top list parent->pname,child->cname cancel I was able to recreate the 1242 error only while in the debugger. One workaround may be to remove debugger code from modules that use set relation (don't use Clipper's /b), or to not use set relation. Internal Error #1256, __DBSETIND(0) (#112199) There were indications that: USE GLOBAL i1 = "globuser" SET INDEX TO &i1 causes this error, when both database and index exist. I was unable to confirm this. (Mail: Del Texley [71117,3551]) Del found that this error may be related in some way to the size of the database. He says that the workaround is to test the number of records before opening the index file, and recreate it if less than 5 records exist. SELECT( SEL_POST ) USE PRPOST INDEX PRPOST // Crash here with internal error # 1256 if // prpost is empty! ** This Fixes if substituted for above line USE PRPOST IF RECCOUNT() <>Emp_num + DTOS( PRPOST->Pdate ) TO PRPOST ELSE SET INDEX TO PRPOST ENDIF ** Weird enough for you? (#112378) This message reports that 1256 occurs during a SET INDEX. The user says that he was using an index expression that contained a UDF for displaying percent done during the index. Clipper 5.0 stores index exp- ressions as it receives them: "INDEX ON A + B" will keep the strange spacing. His problem was that he had a function that was messing with the NTX header, and not taking this into account. Internal Error #2155, _DBSETIND (0) (#104860) Index file corruption. You can get this error if you open an NDX file. Also, the file may be open in another area. If one work area creates an index then another work area tries to open that newly created index, you can get this error. Internal Error #3511 (#107383) Occurred during VM Swap file access on a Novell Network. Returned DOS error 4 - perhaps related to handle problems? Not enough handles for swapfile? Internal Error #5302, VMSWAP (#95585) VMM Problem. Not enough base memory to run program. Free up some base memory by unloading unnecessary TSRs, etc ... remember that BASE memory is the memory below 640K, and a Clipper application needs as much of it as you can dole out. If the computer you are running on is has an 80386sx or better, consider purchasing a high RAM memory manager such as Quarterdeck's QEMM or 386 to the Max. If you are already running such a utility, and are still bonking your cranium against DOS's paltry 640K limit, you may want to try disabling your VGA/EGA adaptor's graphics capability to create excess contiguous free DOS space (sometimes up to as much as 800K!). QEMM's command to do this is VIDRAM [OFF|ON]. Some systems do not allow for this option, so check your 386 memory manager's documentation for details. Internal Error #5305 VMM Problem. (Mail: John Farrar [100015,502]) John says he encountered 5305 while ~ executing this code: LOCAL aDept := {} DBEval({|| AADD(aDept, DEPT->(FieldGet(1)))}) ... on a database of 1 field and 26 records. I was unable to verify that this occurs consistently. See Also: "Internal Error #5302" Internal Error #5317, __DBCREATI (0) (#95574) Not enough base memory during index create. See Also: "Internal Error #5302" Internal Error #5318, __RUN (0) (#96064) VMM Problem. RUN command. (#108539) Memory problem. Running on PCMOS system. (#113750) If you are getting this error using RUN on PC-MOS, check out PCMOS.ZIP in LIB 4. It contains several assembly functions that work with Clipper and PC-MOS -- and apparently allow you to circumvent the RUN command all together. Check with the author: Don Caton [71067,1350]. See Also: "Internal Error #5302" Internal Error #5320, __DBCREATI (0) (#94001) Index Problem. (#96249) Sometimes solved by reducing index key size. (#95342) Possibly a conflict with CACHE, VDISK, or SMARTDRV. (#95701) More of the same - May not be CACHE - perhaps combination of key length and available memory. (#95087) Indexing may have problems with macros. Try surrounding your key expression with parenthesis. (#101629) Suggests that perhaps not pre-linking with BASE50 will help. (#108574) One user appended a CHR(0) to the end of his key string at Nantucket's suggestion, and this error went away for good. (#112220) Reports that this error occurred also during a SORT -D in __DBARRANG(0). No resolution was offered. Try the sort in a stand alone program - the problem may be related to the size of the DBF and available memory. (#112803) This error seems to occur when clipper thinks you have expanded memory, but you do not. Installing expanded memory has been known to solve it. No guaranties, but it could be worth a try. It also seems Smartdrv.sys is usually installed at the time. (#112960) In essence, the 5320 means the VMM has tried to map an EMS page when no EMS is available or that the EMS manager has returned an error code. () Most of the 5320 reported errors have been on INDEXing or SORTing operations. (PACKs with NTXs open, REPLACING a key field, etc...) Since 5320 is in the VMM error range (53xx), this would indicate that 5320 has something to do with indexes related to VMM. VMM is used for buffers, variables, and clipper code. It should be noted that 53xx does not necessarily mean that there is a low memory problem - any VMM problem will do. (Mail: 71660,1440) While installing a Clipper 5.0 program on a Novell ~ Network, this user solved continuous 5320 errors by switching from DOS 3.3 to 4.x. I personally believe that the switch in DOS versions was not the deciding factor, and that perhaps a change in EMS Driver or General RAM configuration during the OS switch caused the errors to disappear. (#117235) Ray Crisp [73667,1450] solved his 5320 woes by changing the ~ following code: SELECT 1 USE ARTRANS INDEX ON VndNo+FileNo+STR(TransNo) TO ARTRANSA INDEX ON FileNo+STR(TransNo) TO ARTRANSF CLOSE DATABASES // Ray Added this, and ... SELECT 1 // this, and his problems disappeared USE ARFILE INDEX ON FileNo TO ARFILE // etc ... (#115909) Kurt Schaldenbrand [72137,2703] suggests that this error is ~ related in some way to expanded memory: "When a customer adds expanded memory, occurrences of both 416 and 5320 go away." See Also: "Internal Error #416" Internal Error #5321, __DBREINDE (0) (Mail: Greg Dahl [72050,650]) This error occurred when VMM had run out of disk space during a reindex. Internal Error #5333 (#98457) Macro expanded to a local variable. Means that VMM has died with a reference to an invalid or NULL memory pointer. (#114101) One user says that perhaps changing PRIVATE or PUBLIC variables to LOCAL or STATIC may affect this error. (#114263) This suggests that perhaps getting a macro variable: GET &mtest where mtest is a public, may cause the problem. I was unable to duplicate this. () I was able to get an internal error #5333 by declaring a local array larger than 4096 (we'll say 'x'), then accessing an array element beyond x % 4096. For instance: LOCAL aList[5000] aList[769] := "Hello World" (Mail: Greg Dahl [72050,650]) While using Roger Donnay's MEM50, Greg got ~ IE 5333 REFRESHCUR(0) after making a data change using DBEDIT(). Some symbol is apparently not available for DBEDIT() that should be. Not using MEM50 eliminated the problem. (#116024) In this thread, a user was battling with a #5333 error that ~ kept popping up during a READ. He solved the problem by doing a CLEAR GETS immediately before the first @ GET was issued.

Accuracy ...

How Accurate is the info in this guide? Where I was unable to determine the nature of a specifc error, you'll see that I've left hints and notes from other people who have recevied the error. These people are the wonderous Clipper community -- they hang out on Nanforum on CIS, and are really neat folks. Most of the time, they know what they are talking about. Items that are displayed in this color in error descriptions are quotes or paraphrases from Nantucket personnel. Those funny numbers ... The numbers in parenthesis are message and thread numbers from Nanforum where the explanation of the error was extracted. In some cases, due to lack of source code or other factors I've made no attempt to verify the error as reported. However, those errors marked with empty parenthesis have been verified by me. When possible, code or methods that will faithfully reproduce the errors where reported. If there is no such listing of code, then, once again, the errors have not been verified. Verification Equipment & stuff ... Where I was able to verify errors, the following configuration was used: Clipper 5.0 Revision 1.03, 592K free base memory (using EATMEM.COM to reduce available base memory if necessary), Compaq 80386s, 4.5 Meg memory managed by QEMM, DOS V4.01 w/Novell netware IPX, and NET4XMS loaded high.

Credits ...

Clipper 5.0 Internal Errors, V1.03 (9104.01) - Terry McConnell This error list is not a publication of Nantucket corporation. This list was compiled based on the messages posted on Compu-Serve's Nanforum between November 1, 1990 and the date that appears on this file. Updates ... I will be making frequent updates to this guide and I will make these updates available on the DBADVISOR forum, and the NANFORUM on CIS until Nantucket(r) produces a fix disk or provides developers with an accurate internal error listing. Feel free to distribute these freely. Comments, suggestions, addendums, changes, and corrections to this thing can be mailed to me, Terry McConnell 71570,3571 on Compu-Serve. All changes to this guide from its previous version are marked with a squiggly thing (tilde'). (~) Thanks ... Special thanks to all those who have helped me to compile this list, and thanks to Jo W. French for the inspiration, and the anomaly reports. The only way that this list could have been compiled was with the replies & help that Nanforum developers have given to other developers. Thank you to every person who has ever taken the time to help another developer, and to those who have made it a habit.

No comments:

Post a Comment

Welcome to Clipper... Clipper... Clipper

In 1997, then using Delphi 3, I had already created 32-bits Windows applications for HRIS, ERP and CRM. In 2007, using Ruby on Rails, an AJAX powered CRM site running on Apache & MySQL was created and I am now using Visual Studio .Net 2008 to create web-based projects and Delphi 7 for Win32 applications using SQL2005 & DBFCDX.

So, why then am I reviving the Original Clipper... Clipper... Clipper via a Blog as CA-Clipper is a programming language for the DOS world ? Believe it or not, there are still some clients using my mission-critical CA-Clipper applications for DOS installed in the late 80's and up to the mid 90's. This is testimony to CA-Clipper's robustness as a language :-)

With the widespread introduction of Windows 7 64-bits as the standard O/S for new Windows based PCs & Notebooks, CA-Clipper EXE simply will not work and it has become imperative for Clipper programmers to migrate immediately to Harbour to build 32/64 bits EXEs

Since 28th January 2009, this blog has been read by 134,389 (10/3/11 - 39,277) unique visitors (of which 45,151 (10/3/11 - 13,929) are returning visitors) from 103 countries and 1,574 cities & towns in Europe (37; 764 cities), North America (3; 373 cities) , Central America & Caribeans (6; 13 cities), South America(10; 226 cities), Africa & Middle-East (12; 44 cities) , Asia-Pacific (21; 175 cities). So, obviously Clipper is Alive & Well : -)

TIA & Enjoy ! (10th October 2012, 11:05; 13th November 2015)

Original Welcome Page for Clipper... Clipper... Clipper

This is the original Welcome Page for Clipper... Clipper... Clipper, which I am republishing for historical and sentimental reasons. The only changes that I have made was to fix all the broken links. BTW, the counter from is still working :-)

Welcome to Chee Chong Hwa's Malaysian WWW web site which is dedicated to Clipperheads throughout the world.

This site started out as a teeny-weeny section of Who the heck is Chee Chong Hwa ? and has graduated into a full blown web site of more than 140 pages (actually hundreds of A4 size pages) ! This is due to its growing popularity and tremendous encouragements from visiting Clipperheads from 100 countries worldwide, from North America, Central America, Caribbean, South America, Europe, Middle-East, Africa and Asia-Pacific. Thanx Clipperheads, you all made this happen !

What is Clipper ?

You may ask, what is this Clipper stuff ? Could Clipper be something to do with sailing as it is the name of a very fast sailing American ship in the 19th century ?

Well, Clipper or to be precise, CA-Clipper is the premier PC-Software development tool for DOS. It was first developed by Nantucket Corporation initially as a compiler for dBase3+ programs. Since then, CA-Clipper has evolved away from its x-base roots with the introduction of lexical scoping & pre-defined objects like TBrowse. As at today, the most stable version ofClipper is 5.2e while the latest version, 5.3a was introduced on 21 May 1996.

As at 11th November, 1996, an unofficial 5.3a fixes file was made available by Jo French. See the About CA-Clipper 5.3a section for more details. BTW, Jo French uploaded the revised 5.3a fixes file on 20th November, 1996.

Latest News

The latest news is that CA has finally released the long-awaited 5.3b patch on 21 May, 1997.

For 5.3b users, you must a take a look at Jo French's comments on unfixed bugs in 5.3b.

BTW, have you used Click ? If you're a serious Clipperprogrammer and need an excellent code formatter, Click is a natural choice. How to get it ? Simple, access Phil Barnett's site via my Cool Clipper Sites.

32-bits Clipper for Windows ?

Have you tried Xbase ++ ? Well, I have and compared to Delphi (my current Windows programming tool of choice), I'm still sticking to Delphi.

Anyway, you should visit the Alaska Home Page. Give it a chance and then draw your own conclusions !.

The Harbour Project

Is this the future of Xbase ? Take a look at at the Harbour Project

You are Visitor # ...

According to, you are visitor since 3 June 1996.

If you like or dislike what you see on this website, please drop me a line by clicking the email button at the bottom of this page or better still, by filling out the form in my guest book. If you are not sure what to write,click here to take a look at what other Clipperheads have to say.