DBU - Database Utility - No of files 1

[AndrewMozley]

I have this utility, DBU.EXE from way back when (inc source), and I still use it for examining tables if .ntx indexes are being used.

However the program is liable to crash (not through the Clipper error handler, sadly), if there are more than a certain number (perhaps 4K) of tables in the current folder. I suppose it is possible that these names are being read into an array with a 4K limit. This happens even if these tables are not of interest to the current enquiry. (The problem arises because I keep old sales invoices as .dbf files and have failed to develop a scheme for archiving them automatically)

Does anyone have a corrected version which avoids the problem? I suppose that I could trawl through the source code and correct it, but if someone has been that way before, I would be grateful for an amended version.

Thanks.

 

[lohen]

if this is 5.2(e) link dbu for protected mode,

// dbu.lnk

blinker executable extended
blinker incremental off
blinker overlay opsize 25
blinker procedure depth 70
blinker cache ems 100%, 1024
blinker overlay pageframe on
blinker executable clipper F81

stack 8192

file dbu
file dbuutil
file dbuhelp
file dbuview
file dbuindx
file dbuedit
file dbucopy
file dbustru
file dbunet

search blxclp52

lib clipper
lib extend
lib dbfntx
lib terminal

hth

regards

 

[AndrewMozley]

Thanks for that, Iohen. I will compare it with my existing dbu.lnk. Do I understand you to be saying that this link will resolve the problem whereby dbu crashes if there are too many dbf files?

Amndrew

 

[lohen]

Wel, you mentioned it yourself, dbu pbly uses DIRECTORY() which return value, as an array is limited to 4096 elements; however, this limit is theoretical, also depending on available pool memory; the best chance to get closer to that limit is a protected mode executable using extended memory also, but if you know in advance your folder contains more than that number of files, pbly you'll save yourself a headache locating a version of Blinker; otoh, the script mentioned also works with Causeway which is free

http://www.devoresoftware.com/freesource/cwsrc.htm

(CWBLOOM.ZIP iirc)

As to Clipper 5.3(b), there's a stripped down version of Blinker (1.5) included; better use a standalone version (latest 7.0 is available

http://www.grafxsoft.com)

Syntax:

Blinker @dbu.lnk

Finally, ExoSpace (clipper 5.3 or standalone version) can be used also but i have no specifics about what needs in the link script

Best regards,

Frank

 

[AndrewMozley]

Thank you Frank.

I do indeed use Blinker as my Link program. Are you saying that if I modify my link file as you have suggested, that my problem will be solved - that dbu.exe will no longer crash if there are too many .dbf files in the folder? Have you been able to test this on your system.

Regards. Andrew

 

[AndrewMozley]

I'll try again!

Thank you Frank.

I do indeed use Blinker as my Link program. Are you saying that if I modify my link file as you have suggested, that my problem will be solved - that dbu.exe will no longer crash if there are too many .dbf files in the folder? Have you been able to test this on your system.

Regards. Andrew

 

[lohen]

as you haven't mentioned what version you are using, i had it tested for both 5.2e and 5.3b

the 5.2e Blinker (PM) executable strangely processes a DIRECTORY() call returning an array of beyond 4096 elements (4679 at most before crashing!!!)
the 5.3b Blinker (PM) executable stops at 4096 elements, even if there's a larger number of files that match

i guess it's a 5.2e flaw .oO i wasn't aware of

i've tried linking OM.OBJ from 5.3b CLIPPER.LIB with 5.2e but it didn't help either; difficult to pinpoint where to look for a correction

Anyway, it's documented that arrays can contain 4096 elements at most, which 5.3b DIRECTORY() behaviour confirms

Best regards,

Frank

 

[TonHu]

You could switch to Harbour-project / xHarbour compilers to release the 4k array size limit, and other old, DOS-based, Clipper-specific limitations.

 

[lohen]

Hi again,

fwiw, here's how to patch your Clipper 5.2e DBU sample:

add DBUADIR.PRG
------------------
FUNCTION adir ( cSkeleton, aNames ) // tailored for use with Clipper 5.2e DBU sources
LOCAL nResult, aResult, nLen, n, nTo

IF aNames == NIL
RETURN LEN( LF_DIRECTORY( cSkeleton )) - 20
END

aResult := LF_DIRECTORY( cSkeleton )
nResult := LEN( aResult ) - 20
nLen := LEN( aNames )
nTo := MIN( nResult, nLen )

FOR n := 1 TO nTo
aNames[ n ] := aResult[ n, 1 ]
NEXT

RETURN nResult
--------------------------

update dbu.rmk
--------------------------
dbu.obj: dbu.prg
...
dbuadir.obj: dbuadir.prg

dbu.exe: dbu.obj dbuutil.obj dbuhelp.obj dbuview.obj dbuindx.obj dbuedit.obj dbucopy.obj dbustru.obj dbunet.obj dbuadir.obj
blinker @dbu.lnk
--------------------------

update dbu.lnk
--------------------------
blinker executable extended
blinker incremental off
blinker overlay opsize 25
blinker procedure depth 70
blinker cache ems 100%, 1024
blinker overlay pageframe on
blinker executable clipper F81

stack 8192

file dbu
file dbuutil
file dbuhelp
file dbuview
file dbuindx
file dbuedit
file dbucopy
file dbustru
file dbunet
file dbuadir

search blxclp52

lib lfn
lib ll
lib cpmi
lib nanfor

lib clipper
lib extend
lib dbfntx
lib terminal
--------------------------

download lfn.lib/ll.lib

http://www.engwall.com/download/lfnlib/lfnlib.zip

download cpmi.lib/nanfor.lib

http://www.the-oasis.net/files/library/nflib305.zip

place new *.lib files in SOURCE\DBU folder

rmake dbu.rmk

You pbly had found another way around it already, but just in case

hth

Frank

 

[lohen]

Sorry, make that

DBUADIR.PRG
------------------
FUNCTION adir ( cSkeleton, aNames ) // tailored for use with Clipper 5.2e DBU sources
LOCAL nResult, aResult, nLen, n

nResult := LEN( aResult := LF_DIRECTORY( cSkeleton ))
nResult -= IIF( nResult >= 4076, nResult - 4076, 0 )

IF aNames != NIL

nLen := MIN( nResult, LEN( aNames ))

FOR n := 1 TO nLen
aNames[ n ] := aResult[ n, 1 ]
NEXT

END

RETURN nResult
--------------------

this should work