Home > Archive > Clipper > September 2006 > ? summer 87 4am .lib files needed
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
? summer 87 4am .lib files needed
|
|
| Gizmo Smith 2006-09-16, 7:55 am |
| I have an application that has been running sucessfully since 1990.
It is written in summer 87 ( with one asm obj to set the epoch for the y2k
thing ),
linked with Borlands' Turbo linker.
It has just got too large to reindex - produces an out of memory error on
reindexing.
There are 10,000 lines of code (exe 288 k), 14 dbf's, 21 index's.
The largest DBF has 18,278 records and is 9.3 mb in size,
deleting a few, (100) records cures everything.
Do I need the 4am time stamped clipper.lib and extend.lib files ? ( I am
using the 2am ones)
Or can I use Blinker to create an .exe that can utilise more extended
memory ?
| |
| pete@nospam.demon.co.uk 2006-09-16, 6:55 pm |
| In article <450bdac7$0$7308$5a62ac22@per-qv1-newsreader-01.iinet.net.au>
smiffs5@yahoo.com.sg "Gizmo Smith" writes:
> I have an application that has been running sucessfully since 1990.
> It is written in summer 87 ( with one asm obj to set the epoch for the y2k
> thing ), linked with Borlands' Turbo linker.
> It has just got too large to reindex - produces an out of memory error on
> reindexing.
> There are 10,000 lines of code (exe 288 k), 14 dbf's, 21 index's.
> The largest DBF has 18,278 records and is 9.3 mb in size,
> deleting a few, (100) records cures everything.
Those numbers don't seem too horrendous -- the app that I used to
look after was larger than 288KB and managed DBFs of ~300MB (this
was S'87 also). It was however heavily overlaid; is your app?
> Do I need the 4am time stamped clipper.lib and extend.lib files ? ( I am
> using the 2am ones)
Possibly, though the 4am lib was AIUI produced to fix a somewhat
obscure indexing bug in the 2am version. Certainly it's no
smaller or would use less memory.
> Or can I use Blinker to create an .exe that can utilise more extended
> memory ?
Maybe -- wait for the Blinker experts to reply :-) Either that
or look into overlaying your app (or rearranging the overlaying
scheme) to reduce the conventional memory footprint.
Pete
--
"We have not inherited the earth from our ancestors,
we have borrowed it from our descendants."
| |
| Robert Haley 2006-09-16, 6:55 pm |
| Greetings,
> ... It has just got too large to reindex - produces an out of memory error on
> reindexing.
> There are 10,000 lines of code (exe 288 k), 14 dbf's, 21 index's.
> The largest DBF has 18,278 records and is 9.3 mb in size,
> deleting a few, (100) records cures everything.
Have you tried:
1) Add SET INDEX TO / CLOSE DATABASE following indexing each index,
e.g.:
USE MYDBF EXCLUSIVE
INDEX ON LAST + FIRST TO CUSTNAME
* CREATE THE INDEX..
SET INDEX TO
* CLOSE INDEX !
INKEY(.5)
* ALLOW FOR OS OVERHEAD TO WRITE INDEX &
* FOR SUMMER 87 GARBAGE COLLECTION..
INDEX ON CUSTNO TO CUSTNUM
SET INDEX TO
INKEY(.5)
....
....
SET INDEX TO
CLOSE DATABASE
2) Calculating the total (bytes needed) of the Index key in question,
e.g. the index that is causing the (out of memory) issue?
Total (swapfile) bytes needed should be approximately:
( Total # of records in .DBF ) * ( Size of Index Key )
>
> Do I need the 4am time stamped clipper.lib and extend.lib files ? ( I am
> using the 2am ones)
>
Running with CLIPPER.LIB 4am in production would not be a bad thing - I
can vouch for it running well in a production environment. There was
no 4am version of EXTEND.LIB, AFAIK.
> Or can I use Blinker to create an .exe that can utilise more extended memory ?
By virtue of overlaying a greater portion of CLIPPER.LIB / EXTEND.LIB
code (CL87MIN/MID/MAX.LNK),
Blinker's better DPMI/XMS/EMS management,
and using Blinker's Summer '87 Memory pack feature ( BLINKER MEMORY
PACK (n) ) the potential answer is "Yes",
although it does sound like you are hitting the swapfile max size when
indexing (2) above, vs. a "memory" issue. Freeing up more memory may
help though.
** Not a Blinker expert** (Hi Pete :-)
HTH & Regards,
Bob
| |
|
| Gizmo,
Tlink was always quick but could never overlay. Get a blinker or
another overlay linker and you are good to go. Your app is of modest
size. Blinker link scripts have been posted here.
Mike
Gizmo Smith wrote:
> I have an application that has been running sucessfully since 1990.
> It is written in summer 87 ( with one asm obj to set the epoch for the y2k
> thing ),
> linked with Borlands' Turbo linker.
> It has just got too large to reindex - produces an out of memory error on
> reindexing.
> There are 10,000 lines of code (exe 288 k), 14 dbf's, 21 index's.
> The largest DBF has 18,278 records and is 9.3 mb in size,
> deleting a few, (100) records cures everything.
>
> Do I need the 4am time stamped clipper.lib and extend.lib files ? ( I am
> using the 2am ones)
> Or can I use Blinker to create an .exe that can utilise more extended
> memory ?
| |
| Nick Ramsay 2006-09-17, 3:55 am |
| On Sat, 16 Sep 2006 15:50:49 +0000 (UTC), pete@nospam.demon.co.uk
wrote:
>In article <450bdac7$0$7308$5a62ac22@per-qv1-newsreader-01.iinet.net.au>
> smiffs5@yahoo.com.sg "Gizmo Smith" writes:
>
>
>Those numbers don't seem too horrendous -- the app that I used to
>look after was larger than 288KB and managed DBFs of ~300MB (this
>was S'87 also). It was however heavily overlaid; is your app?
>
>
>Possibly, though the 4am lib was AIUI produced to fix a somewhat
>obscure indexing bug in the 2am version. Certainly it's no
>smaller or would use less memory.
>
Hi Pete
The "somewhat obscure bug" was, in fact, a "magic number" problem with
indexing. It sounds like the OP has stumbled across exactly this
problem. The formula to determine if it is the magic number problem
is:
int(64512 / (len(INDEX_KEY) + 4))
eg. a 10-byte key has a magic number of 4608
| |
| Sylvain Larche 2006-09-17, 7:55 am |
| Gizmo Smith wrote:
> I have an application that has been running sucessfully since 1990.
> It is written in summer 87 ( with one asm obj to set the epoch for the y2k
> thing ),
> linked with Borlands' Turbo linker.
> It has just got too large to reindex - produces an out of memory error on
> reindexing.
> There are 10,000 lines of code (exe 288 k), 14 dbf's, 21 index's.
> The largest DBF has 18,278 records and is 9.3 mb in size,
> deleting a few, (100) records cures everything.
>
> Do I need the 4am time stamped clipper.lib and extend.lib files ? ( I am
> using the 2am ones)
> Or can I use Blinker to create an .exe that can utilise more extended
> memory ?
>
>
>
If you can recompile the application with clipper 5.2e then i would
suggest using causeway (Free linker) that generate VERY fast application
and also requires only 256K free memory.
www.devoresoftware.com/freesource/cwsrc.htm
if you need a linking script let me know.
Sylvain Larche
IoSys Technologie Inc.
iosys@videotron.ca
| |
| Gizmo Smith 2006-09-17, 7:55 am |
| Pete, Nick, Bob, Mike & Ross
Thanks all very much for replying
After much testing:
Blinker 6.0 : Has some nice features, also some complexity - made little
difference to this problem
Any one of these index's will cause an out of memory error :
index on IIF(i_printed,"Y","N") TO i_print
index on IIF(r_printed,"Y","N") TO r_print
index on ref_id TO inv_ref
index on IIF(banked,"Y","N") TO banked
All these index keys are very short
Increasing the length of the index key by padding with a space fixes things
:
index on IIF(i_printed,"Y","N")+" " TO i_print
index on IIF(r_printed,"Y","N")+" " TO r_print
index on ref_id+" " TO inv_ref
index on IIF(banked,"Y","N")+" " TO banked
It does appear to be some sort of not so magic number thing,
where increasing the size of the index key somehow allows the index to fit
in some S87 specification.
If anyone can send me the 4am obj or lib I wouldn't mind trying it to see if
it works
Thanks
Paul
( Ross, Gizmo is my dog, I have a hope that using his name may reduce my
spam )
| |
|
|
Sorry my Blinker suggestion did not work for you. I have one app
running about 10 times that size, no problem.
| |
| Robert Haley 2006-09-17, 6:55 pm |
|
Greetings Gizmo & Paul :-),
> If anyone can send me the 4am obj or lib I wouldn't mind trying it to see if
> it works
>
Sent the (4am) US version of CLIPPER.LIB
to your smif...@yahoo.com.sg address today.
Regards,
Bob
| |
| pete@nospam.demon.co.uk 2006-09-18, 3:55 am |
| In article <450d48c6$0$7313$5a62ac22@per-qv1-newsreader-01.iinet.net.au>
smiffs5@yahoo.com.sg "Gizmo Smith" writes:
Paul,
> Pete, Nick, Bob, Mike & Ross
>
> Thanks all very much for replying
> After much testing:
> Blinker 6.0 : Has some nice features, also some complexity - made little
> difference to this problem
>
> Any one of these index's will cause an out of memory error :
>
> index on IIF(i_printed,"Y","N") TO i_print
> index on IIF(r_printed,"Y","N") TO r_print
> index on ref_id TO inv_ref
> index on IIF(banked,"Y","N") TO banked
Apart from the 3rd one, those index expressions appear very
strange to me. That's to say if, for example 'i_printed' in the
DBF is .t., the index line is effectively
index on "Y" TO i_print
What is _that_ supposed to do? Where does the "Y" fit in? If
the aim is to "split" the DBF in order to place all the like
'i_printed' rows together, perhaps you should be adding at least
one field from the DBF, for example:
index on IIF(i_printed,"Y","N")+CUSTOMER TO i_print
Any CHAR field would do since the Y or N at the front would be
overriding for ordering.
> All these index keys are very short
> Increasing the length of the index key by padding with a space fixes things
> :
>
> index on IIF(i_printed,"Y","N")+" " TO i_print
> index on IIF(r_printed,"Y","N")+" " TO r_print
> index on ref_id+" " TO inv_ref
> index on IIF(banked,"Y","N")+" " TO banked
>
> It does appear to be some sort of not so magic number thing,
> where increasing the size of the index key somehow allows the index to fit
> in some S87 specification.
Not exactly related to your problem, but I found a similar thing
a while back with an odd-length index. The original index was a
C12 plus a C5 (17 bytes) and the record retrieval speed was
really bad, so I added a CHR(0) to the end of the expression and
retrieval speed went to near instantaneous (I exaggerate, but the
improvement was astonishing).
I never did find out why...
Pete
--
"We have not inherited the earth from our ancestors,
we have borrowed it from our descendants."
| |
| AnthonyL 2006-09-18, 7:55 am |
| On Mon, 18 Sep 2006 05:28:58 +0000 (UTC), pete@nospam.demon.co.uk
wrote:
>In article <450d48c6$0$7313$5a62ac22@per-qv1-newsreader-01.iinet.net.au>
> smiffs5@yahoo.com.sg "Gizmo Smith" writes:
>
>Paul,
>
>
>Apart from the 3rd one, those index expressions appear very
>strange to me. That's to say if, for example 'i_printed' in the
>DBF is .t., the index line is effectively
>
> index on "Y" TO i_print
>
>What is _that_ supposed to do? Where does the "Y" fit in? If
>the aim is to "split" the DBF in order to place all the like
>'i_printed' rows together, perhaps you should be adding at least
>one field from the DBF, for example:
>
> index on IIF(i_printed,"Y","N")+CUSTOMER TO i_print
>
>Any CHAR field would do since the Y or N at the front would be
>overriding for ordering.
>
>
Some good points here. I seem to recall that too many records with
the same index key caused problems with our Clipper apps and we made a
rule to add the record number (str(recno(),6) to many indexes
especially where they were simply .t. or .f. or similar.
--
AnthonyL
| |
| Gizmo Smith 2006-09-18, 9:55 pm |
| Pete Nick Bob Mike Sylvian Anthony
Thanks for your replies
It's always very hard to figure out what other peoples uncommented code is
doing.
It's a billing program. The three main files are account, invoice and
receipt related on a one account to many invoice and receipt basis.
In the account file there are logical fields <I_printed> and <R_printed> to
flag if an accounts' invoice or receipt has been printed, so for one reason
or another you could print off a batch of invoices or receipts. Similarly
in the receipts file there is a logical field <banked> so you can produce a
list of unbanked cheques for a bank deposit form.
Structure for database : INVOICE.DBF
Field Field name Type Width Dec Start End
1 ACC_NUM Numeric 6 1 6
2 SERV_DATE Date 8 7 14
3 INPATIENT Character 1 15 15
4 REF_ID Character 4 16 19
5 ITEM_NUM Character 5 20 24
6 ITEM_DESC Character 60 25 84
7 ANAES_NUM Character 5 85 89
8 ANAES_DESC Character 60 90 149
9 UNIT Numeric 3 150 152
10 FEE Numeric 8 2 153 160
11 RAWFEE Numeric 8 2 161 168
12 MULT_RULE Logical 1 169 169
13 GST Logical 1 170 170
** Total ** 171
Currently this file has 24192 records. If you <index on ref_id TO inv_ref>
It will produce an out of memory error.
Changing the index to <index on ref_id + " " TO inv_ref> or deleting 200
records or appending 4000 records and it indexed fine.
Likewise if linked with Bob's kindly sent 4am clipper.lib it indexed fine
with any number of records and this worked with all the other indexes. It
didn't seem to matter what linker is used.
Thanks again to all
Paul
| |
|
| Paul,
What is the out of memory error code?
Mike
Gizmo Smith wrote:
> Pete Nick Bob Mike Sylvian Anthony
>
>
>
> Thanks for your replies
>
>
>
> It's always very hard to figure out what other peoples uncommented code is
> doing.
>
> It's a billing program. The three main files are account, invoice and
> receipt related on a one account to many invoice and receipt basis.
>
> In the account file there are logical fields <I_printed> and <R_printed> to
> flag if an accounts' invoice or receipt has been printed, so for one reason
> or another you could print off a batch of invoices or receipts. Similarly
> in the receipts file there is a logical field <banked> so you can produce a
> list of unbanked cheques for a bank deposit form.
>
>
>
> Structure for database : INVOICE.DBF
>
> Field Field name Type Width Dec Start End
>
> 1 ACC_NUM Numeric 6 1 6
>
> 2 SERV_DATE Date 8 7 14
>
> 3 INPATIENT Character 1 15 15
>
> 4 REF_ID Character 4 16 19
>
> 5 ITEM_NUM Character 5 20 24
>
> 6 ITEM_DESC Character 60 25 84
>
> 7 ANAES_NUM Character 5 85 89
>
> 8 ANAES_DESC Character 60 90 149
>
> 9 UNIT Numeric 3 150 152
>
> 10 FEE Numeric 8 2 153 160
>
> 11 RAWFEE Numeric 8 2 161 168
>
> 12 MULT_RULE Logical 1 169 169
>
> 13 GST Logical 1 170 170
>
> ** Total ** 171
>
>
>
> Currently this file has 24192 records. If you <index on ref_id TO inv_ref>
>
> It will produce an out of memory error.
>
> Changing the index to <index on ref_id + " " TO inv_ref> or deleting 200
> records or appending 4000 records and it indexed fine.
>
> Likewise if linked with Bob's kindly sent 4am clipper.lib it indexed fine
> with any number of records and this worked with all the other indexes. It
> didn't seem to matter what linker is used.
>
>
>
> Thanks again to all
>
>
>
> Paul
| |
| Gizmo Smith 2006-09-18, 9:55 pm |
| Mike
it says on line 1 of the screen:
proc REINDEX line71, out of memory Continue?
line 71 of REINDEX.PRG says:
INDEX ON IIF(i_printed,"Y","N") TO i_print
as far as I'm aware its the standard error handler although I have written
non-standard functions for print_error() and open_error()
Cheers
Paul
|
|
|
|
|