DBT file problems... 
Author Message
 DBT file problems...

Is it well known that .DBT files (at least under Clipper) are limited to
32 megs in size and is there a patch for that? The pointer to the next
block in the header gets updated properly but the .DBT block number located
in the .DBF file doesn't. Even though there's 10 bytes to store the block
number in ASCII, when Clipper writes (or read) that block number, it uses
only an word (16 bits, 0-65535) when it should use a doubleword (32 bits).

Because of this, when you reach > 65536 ( multiplied by 512 bytes, this
gives the 32 megs limit) blocks used, the new blocks get written to disk
but when you try to read or write to these blocks again, you don't access
the correct blocks.

Since the problem is both when the block number gets read and written to,
the block number is the .DBF doesn't even contain the correct block number,
only the least significant word is stored.

Anybody knows of any patch for this problem? (I do know that changing the RDD
would certainly correct the problem but if it was possible to correct this
problem without changing it, it would be preferable.)

I know that Clipper 5.2d, 5.2e and it appears that 5.3 (I used DBU.EXE from
5.3 (which is probably compiled with 5.3 ;-) ) and I was able to replicate the
problem) using the DBFNTX RDD have that problem (I think I'll try using the
DBFNDX RDD to see if it makes any difference).

Also why doesn't block 1 (block 0 is the .DBT header) get used? Clipper stores
some eof markers in it but doesn't use it. Shouldn't this be the first block to
be used?

Thanks for any info!

Nicolas Riendeau



Thu, 25 Jun 1998 03:00:00 GMT  
 DBT file problems...

Quote:

> Anybody knows of any patch for this problem? (I do know that changing the RDD
> would certainly correct the problem but if it was possible to correct this
> problem without changing it, it would be preferable.)

Nope, AFAIK there isn't a patch for this "problem". Mostly because it's not
a problem. It's part of the standard for a dBase style DBF/DBT file. They
can't and should not stray from that IMHO, if you want to get round it then
the best answer is to get an RDD that can handle this.

Quote:
> I know that Clipper 5.2d, 5.2e and it appears that 5.3 (I used DBU.EXE from
> 5.3 (which is probably compiled with 5.3 ;-) ) and I was able to replicate
> the problem) using the DBFNTX RDD have that problem (I think I'll try
> using the DBFNDX RDD to see if it makes any difference).

Non of the "standard" RDDs should make a difference because this isn't a
"problem", as I say, it's the actual design of that database layout. That's
the problem with backwards compatability, you get to keep all the old bad
as well as the good stuff.

--
Dave Pearson              | Let us not assasinate this lad further, Senator.

Bass Player for the       |   Have you no sense of decency, Sir?
Cheri-Woodpeckers         |    At long last, have you no sense of decency?



Sat, 27 Jun 1998 03:00:00 GMT  
 DBT file problems...

Quote:

>(I think I'll try using the
>DBFNDX RDD to see if it makes any difference).

As Dave pointed out, this is a standard... although perhaps there
might be a better way for Clipper to handle it than just corrupt the
DBT without warning.

Quote:
>Also why doesn't block 1 (block 0 is the .DBT header) get used? Clipper stores
>some eof markers in it but doesn't use it. Shouldn't this be the first block to
>be used?

I would advise you not to expect any optimizations at all from DBTs.
All that wasted space when updating/etc... is its biggest problem in
my opinion.

gg

------------------------------------------------------------------------
Gabriel B. Gonzalez           Information and Computer Science & Biology


------------------------------------------------------------------------



Sun, 28 Jun 1998 03:00:00 GMT  
 DBT file problems...

Quote:


> >(I think I'll try using the
> >DBFNDX RDD to see if it makes any difference).

> As Dave pointed out, this is a standard... although perhaps there
> might be a better way for Clipper to handle it than just corrupt the
> DBT without warning.

Good point, it would be handy if you got an "Error: I've just shagged your
database" error don't you think? :-)

--
Dave Pearson              | Let us not assasinate this lad further, Senator.

Bass Player for the       |   Have you no sense of decency, Sir?
Cheri-Woodpeckers         |    At long last, have you no sense of decency?



Sun, 28 Jun 1998 03:00:00 GMT  
 DBT file problems...

Quote:

>Subject: Re: DBT file problems...
>Date: Wed, 10 Jan 1996 06:13:24 GMT


>>(I think I'll try using the
>>DBFNDX RDD to see if it makes any difference).
>As Dave pointed out, this is a standard... although perhaps there
>might be a better way for Clipper to handle it than just corrupt the
>DBT without warning.

     To what article/FAQ? are you referring to? I've seen a reply from Dave
but it was a reply to this reply...

Quote:
>>Also why doesn't block 1 (block 0 is the .DBT header) get used? Clipper
stores
>>some eof markers in it but doesn't use it. Shouldn't this be the first
block to
>>be used?
>I would advise you not to expect any optimizations at all from DBTs.
>All that wasted space when updating/etc... is its biggest problem in
>my opinion.

      Yes, I know that the 512 bytes block size and the fact that there is no
epuration ( I'm not sure if that word exists in english... sorry... ) or
re-utilisation of block that are no longer used is a big problem with .DBT
files but I really don't consider that Clipper handles this situation
correctly (It should generate a runtime error ( not continue to add blocks and
incorrectly update the .DBF).

BTW,  the DBFMDX RDD does seem to use the first record of the .DBT. Also,
where the ^&%&$ is that problem documented? (I think I read about it somewhere
(though I'm not quite sure) and I don't know where (it sure doesn't seem to be
in the manuals supplied with Clipper).



Mon, 29 Jun 1998 03:00:00 GMT  
 DBT file problems...

Quote:


>Subject: Re: DBT file problems...
>Date: Wed, 10 Jan 1996 08:17:17 GMT



>> >(I think I'll try using the
>> >DBFNDX RDD to see if it makes any difference).

>> As Dave pointed out, this is a standard... although perhaps there
>> might be a better way for Clipper to handle it than just corrupt the
>> DBT without warning.
>Good point, it would be handy if you got an "Error: I've just shagged your
>database" error don't you think? :-)

     That situation should generate a runtime error, what did they think when
they decided not to trap that error???

Thanks to both of you!

Nicolas Riendeau



Mon, 29 Jun 1998 03:00:00 GMT  
 DBT file problems...

Quote:

>Is it well known that .DBT files (at least under Clipper) are limited to
>32 megs in size and is there a patch for that? The pointer to the next
>block in the header gets updated properly but the .DBT block number located
>in the .DBF file doesn't. Even though there's 10 bytes to store the block
>number in ASCII, when Clipper writes (or read) that block number, it uses
>only an word (16 bits, 0-65535) when it should use a doubleword (32 bits).
>Because of this, when you reach > 65536 ( multiplied by 512 bytes, this
>gives the 32 megs limit) blocks used, the new blocks get written to disk
>but when you try to read or write to these blocks again, you don't access
>the correct blocks.
>Since the problem is both when the block number gets read and written to,
>the block number is the .DBF doesn't even contain the correct block number,
>only the least significant word is stored.
>Anybody knows of any patch for this problem? (I do know that changing the RDD
>would certainly correct the problem but if it was possible to correct this
>problem without changing it, it would be preferable.)
>I know that Clipper 5.2d, 5.2e and it appears that 5.3 (I used DBU.EXE from
>5.3 (which is probably compiled with 5.3 ;-) ) and I was able to replicate the
>problem) using the DBFNTX RDD have that problem (I think I'll try using the
>DBFNDX RDD to see if it makes any difference).
>Also why doesn't block 1 (block 0 is the .DBT header) get used? Clipper stores
>some eof markers in it but doesn't use it. Shouldn't this be the first block to
>be used?
>Thanks for any info!
>Nicolas Riendeau


You must use DBFCDX or COMIX (the best)

+--------------------------------------------+
+  Harry Evans    :: -)                      +
+  Clipper Specialist                        +

+--------------------------------------------+



Wed, 01 Jul 1998 03:00:00 GMT  
 DBT file problems...

Quote:


>> Anybody knows of any patch for this problem? (I do know that changing the RDD
>> would certainly correct the problem but if it was possible to correct this
>> problem without changing it, it would be preferable.)

>Nope, AFAIK there isn't a patch for this "problem". Mostly because it's not
>a problem. It's part of the standard for a dBase style DBF/DBT file. They
>can't and should not stray from that IMHO, if you want to get round it then
>the best answer is to get an RDD that can handle this.

    I switched to DBFCDX for that file (and for now, only that file... I had to correct
that problem ASAP and the programs that use that file are composed of many .PRGs.)

Quote:
>"problem", as I say, it's the actual design of that database layout. That's
>the problem with backwards compatability, you get to keep all the old bad
>as well as the good stuff.

Tsk, Tsk, Tsk... Doesn't Clipper already deviates from the standard by permitting character
fields of more that 255 characters ( 64000 characters I believe...)? At least, that's that I
thought.

Thanks!

Nicolas Riendeau



Sun, 05 Jul 1998 03:00:00 GMT  
 DBT file problems...

Quote:




> > >(I think I'll try using the
> > >DBFNDX RDD to see if it makes any difference).

> > As Dave pointed out, this is a standard... although perhaps there
> > might be a better way for Clipper to handle it than just corrupt the
> > DBT without warning.

> Good point, it would be handy if you got an "Error: I've just shagged your
> database" error don't you think? :-)

being the untrusting soul i am, i frequently pack any dbt that i have to
use... if possible, i try to replace the dbt all together by using a dbf
linked by reference. the overhead in converting to/from memo is worth the
headaches, and no lingering file size creeping....

jim



Mon, 19 Oct 1998 03:00:00 GMT  
 
 [ 9 post ] 

 Relevant Pages 

1. DBT file problem

2. Please help, DBT file problem

3. PROBLEMS WITH DBT FILES

4. Problems with a DBT file (MEMO, fields)

5. File size of Advantage dbt files

6. Clipper .dbt to dBase .dbt?

7. Program Hang - DBT file

8. Access 97 linking to DBF,NTX, DBT Files

9. DBT file

10. Clipper 5.2e And Delphi 5.0 using .DBT memo files

11. export dbf dbt and ntx files ?

12. DBT File and 32 MB Limit

 

 
Powered by phpBB® Forum Software