dBase in Lazarus

[winni]

Hi!

TDbf is NOT a replacement of BDE.

20 years ago there were problems with updating the index file. Hope that it is fixed now.

If your index file is damaged: Throw it away and create a new one.

Tutorial:

https://wiki.freepascal.org/Lazarus_Tdbf_Tutorial

Winni

[iret]

Thank you, that is the information I was looking for, it does not seem to be fixed:-(

BTW: I'm aware that TDbf is not a replacement for BDE, I just wanted to use it to read/write information to one single dbase file that is also used by an BDE application. But of course corrupt index-handling does not allow that.

Already started to use a different approach now

[wp]

Hmm, I thought I could share a dbf file with one of my old Delphi BDE programs which I can not replace right now.

Using TDbf seems to be working, but sometimes (e.g once a day) I get strange errors which seem to be related to a damaged index file.

Maybe I have to write a Delphi Dll now to access the dbase files.

In my experience, bugs most probably are in my own code, only rarely in code of others. And I believe the latter case only when it is possible to reproduce the bug by a simple stand-alone project in which everything has been reduced as much as possible.

I would not attempt to rewrite anything related to dbase - this would keep me busy for the next years.

If you really would come to the conclusion that FPC's code in TDbf is faulty but you cannot provide a simple test project for a bug report for someone of the db devs to have to look at, you could also try to replace the TDbf coming with FPC by the TDbf from its original author's site (https://sourceforge.net/p/tdbf/code/HEAD/tree/trunk/) which is still actively maintained (unlike its fork in FPC).

[iret]

Unfortunately I can not reproduce the behaviour, it simply happens during daily work. Even my users don't recognize the problem directly,  instead they will get an error from my old Delphi application minutes or hours later. Since the Delphi app is running since 2005 without these problems  I'm 99.9% sure the problem is related to my new lazarus app.

Concerning the lazarus app:
  * Reading the content of dbf files is no problem at all
  * Writing to a record also seems to be no problem as long as I don't use the Delphi-App which relies on the index

  * Interesting: Using "locate" is not possible, the DB cursor will not be set to the correct record
      * Hmm, maybe I should take a closer look at this

Thanks for your tips

[wp]

  * Interesting: Using "locate" is not possible, the DB cursor will not be set to the correct record

This statement does not seem to be correct - have a look at the attached minimum sample project which works correctly.

[SymbolicFrank]

How are the index files named?

[rvk]

... I just wanted to use it to read/write information to one single dbase file that is also used by an BDE application. But of course corrupt index-handling does not allow that.

Unfortunately I can not reproduce the behaviour, it simply happens during daily work. Even my users don't recognize the problem directly,  instead they will get an error from my old Delphi application minutes or hours later. Since the Delphi app is running since 2005 without these problems  I'm 99.9% sure the problem is related to my new lazarus app.
//...
  * Writing to a record also seems to be no problem as long as I don't use the Delphi-App which relies on the index

Are you using the Delphi app and Lazarus app at the same time???
Don't do that with dBase files.
You might be lucky to only get index errors. You could also loose ALL data.

[iret]

The index file is a mdx file named like the dbf file: elposi.dbf and elposi.mdx 

Concerning the Locate:

  * If I set "loPartialKey" everything works fine
  * Strange: My Index field is an integer field, the index is unique:  "partialkey" makes no sense here

Digging further:
   
  * The locate only copies 4 digits of my 6 digit search-key into its internal buffer
     --> Yes, that is kind o a partial key...

  * TDbfViewer says: The field is "integer" with a length of 4
     --> Just a wild guess: If TDbf takes 4 as the number of digits instead of using it as number of bytes this could be a reason for locate failing to find my record

I'll try to find out and give some feedback.

BTW: I'm now using TDbf from sourceforge, there's quite a lot of activity and it seems they fixed some issues related to index files

[iret]

@rvk:

I understand it is not recommended nowadays to use dbase files on a shared network drive with multiple clients. On the other hand this has been used by thousands of programmers for more than two decades...

In the long run of course we'll replace the old Delphi app, my current struggling is an attempt to port parts of the app to lazarus/fpc

[HeavyUser]

@rvk:

I understand it is not recommended nowadays to use dbase files on a shared network drive with multiple clients. On the other hand this has been used by thousands of programmers for more than two decades...

lazarus tdbf does not support sharing. You are corrupting your data.

In the long run of course we'll replace the old Delphi app, my current struggling is an attempt to port parts of the app to lazarus/fpc

you need to rethink your intermediate steps for porting. They need to be bigger. Maybe port the delphi dbase libraries to lazarus first which supports sharing.

[rvk]

I understand it is not recommended nowadays to use dbase files on a shared network drive with multiple clients. On the other hand this has been used by thousands of programmers for more than two decades...

Some dBase drivers and libraries build in some form of locking mechanisme (BDE does have such a form of locking scheme). But when you are mixing different dBase drivers (like BDE and Lazarus) and do simultaneous access you are guaranteed to have corruption. First in the index files (because they are more prone to these kind of corruption) but ultimately also in your actual data-file.

Stick to ONE kind of dBase driver at a time (and find out if it has some locking among different clients) or upgrade to another database engine.

(I'm not aware that TDBF has a locking scheme so don't use that with multiple clients, PERIOD)

[MarkMLl]

I understand it is not recommended nowadays to use dbase files on a shared network drive with multiple clients. On the other hand this has been used by thousands of programmers for more than two decades...

It never was recommended, and the fact that people were usually able to get away with it is absolutely no justification.

Affordable multiuser-safe database backends started to appear circa 1990, and affordable SQL servers circa 2000. There is no excuse these days for not doing the job properly.

MarkMLl

[winni]

Hi!

Finally you got two solutions:

* Move to SQL as I told you in post #9
* Rewrite the BDE which is not an easy job, because it is closed source of Borland/Embarcardero. Then you can continue with your beloved dBase files.

Winni

[wp]

My Index field is an integer field [...] TDbfViewer says: The field is "integer" with a length of 4
     --> Just a wild guess: If TDbf takes 4 as the number of digits instead of using it as number of bytes this could be a reason for locate failing to find my record

Did you specify the Size of the integer field as 4, based on your knowledge that this is the size of an integer? I never did this... I never specify the Size of fields with well-defined size (making it 0 internally, and TDataset can handle this automatically).

[winni]

  * TDbfViewer says: The field is "integer" with a length of 4
     --> Just a wild guess: If TDbf takes 4 as the number of digits instead of using it as number of bytes this could be a reason for locate failing to find my record

Hi!

That is not just a wild guess but true:

Even for an int16 you have to declare 6 for 6 digits: -32767
dBase saves integers (and floats) as digits!!!

Set it to zero and let the system decide.

Winni