tags:

views:

25

answers:

1

ISQL-SE 4.10.DD6 (DOS 6.22):

BCHECK  C-ISAM B-tree Checker version 4.10.DD6  

C-ISAM File: c:\dbfiles.dbs\*.*

ERROR: cannot open C-ISAM file

In SE2.10 it worked with wilcards * .* for all files, but in SE4.10 it doesn’t. I have an SQL script which my users periodically run to reorg customer and transactions tables. Then I have a FIX.BAT DOS script [bcheck –y * .*] as a utility option for my users in case any tables get screwed up. Since users running the reorg will now increment the table version number, example: CUSTO102, 110, … now I’m going to have to devise a way to strip the .DAT extensions from the .DBS dir and feed it to BCHECK. Before, my reorg would always re-create a static CUSTOMER.DAT with CREATE TABLE customer IN “C:\DBFILES.DBS\CUSTOMER”; but that created the write permission problem and had to revert back to SE’s default datafile journaling…

Before running BCHECK on CUSTO102, its .IDX file size was 22,089 bytes and its .DAT size is 882,832 bytes.

After running BCHECK on CUSTO102, its .IDX size increased to 122,561 bytes, however a new .IDY file was created with 88,430 bytes..

What's a .IDY file ???

C:\DBFILES.DBS> bcheck –y CUSTO102

BCHECK  C-ISAM B-tree Checker version 4.10.DD6  

C-ISAM File: c:\dbfiles.dbs\CUSTO102

Checking dictionary and file sizes.
Index file node size = 512
Current C-ISAM index file node size = 512
Checking data file records.
Checking indexes and key descriptions.
Index 1 = unique key  
    0 index node(s) used -- 1 index b-tree level(s) used
Index 2 = duplicates  (2,30,0) 
    42 index node(s) used -- 3 index b-tree level(s) used
Index 3 = unique key  (32,5,0) 
    29 index node(s) used -- 2 index b-tree level(s) used
Index 4 = duplicates  (242,4,2) 
    37 index node(s) used -- 2 index b-tree level(s) used
Index 5 = duplicates  (241,1,0) 
    36 index node(s) used -- 2 index b-tree level(s) used
Index 6 = duplicates  (46,4,2) 
    38 index node(s) used -- 2 index b-tree level(s) used
Checking data record and index node free lists.

ERROR: 177 missing index node pointer(s)
Fix index node free list ? yes

Recreating index node free list.
Recreating index 6.
Recreating index 5.
Recreating index 4.
Recreating index 3.
Recreating index 2.
Recreating index 1.
184 index node(s) used, 177 free -- 1083 data record(s) used, 0 free
+1  A: 

The problem with the wild cards is more likely an issue with the command interpreter that was used to run bcheck than with bcheck itself. If you give bcheck a list of file names (such as 'abc def.dat def.idx', then it will process the C-ISAM file pairs (abc.dat, abc.idx), (def.dat, def.idx) and (def.dat, def.idx - again). Since it complained about being unable to open 'c:\dbfiles.dbs\*.*', it means that the command interpreter did not expand the '*.*' bit, or there was nothing for it to expand into.

I expect that the '.IDY' file is an intermediate used while rebuilding the indexes for the table. I do not know why it was not cleaned up - maybe the process did not complete.

About sizes, I think your table has about 55,000 rows of size 368 bytes each (SE might say 367; the difference is the record status byte at the end, which is either '\0' for deleted or '\n' for current). The unique index on the CHAR(5) column (index 3) requires 9 bytes per entry, or about 56 keys per index node, for about 1000 index nodes. The duplicate indexes are harder to size; you need space for the key value plus a list of 4-byte numbers for the duplicates, all packed into 512-byte pages. The 22 KB index file was missing a lot of information. The revised index file is about the right size. Note that index 1 is the 'ROWID' index; it does not occupy any space. (Index 1 is also why although every table created by SE is stored in a C-ISAM file, not all C-ISAM files are necessarily compatible with SE.)

Jonathan Leffler
Then I cant understand why with ISQL 2.10, bcheck was able to process with *.* and 4.10 couldn't.. seems like this version of bcheck automatically appends .IDX to the supplied filename(s) and if I supply it CUSTO102.DAT or .IDX, it interprets it as CUSTO102.DAT.IDX and bombs out?.. The 22KB index was a result of creating the database, creating the table, loading the .unl file and creating all the indexes and nothing else, so something's wrong.. perhaps ISQL 4.10 (DOS) was only supported on DOS 5.0, not 6.22 like I'm using + my HIMEM is version 3.x, not 2.x
Frank Computer