TDBF vs TurboPower FlashFiler

[Graeme]

Hi,

I'm again revisiting the idea of porting FlashFiler to FPC, but trying to justify if it is worth it or not. The NexusDB owner offered me (at one stage) a possible license deal in porting NexusDB to FPC too.

My goal - have a database 100% compiled into the executable.

At this point I'm looking for local access only. So how does TDBF compare to FlashFiler?

* Both support local databases
* Both store a db table per file
* TDBF uses external files for indexes. Not sure what FlashFiler
does.
* TDBF is local database only. FlashFiler is local and client/server.


On the other hand, NexusDB surpassed FlashFiler in features. eg: Views, Stored Procedures (which I never use), more up to date SQL syntax, and very very nice FTS (full-text search) support. I've never seen the NexusDB code, so I have no clue how "portable" it is though.

The pros for TDBF and FlashFiler is 100% free. Benefits will be easy deployment even for platforms like FreeBSD, OSX and probably even Android.

Please don't mention SQLite - I'm not interested in that. I'm also well versed on Firebird Embedded (I'm a big fan of Firebird) - and I fully know the deployment issues under OSX, and no official support for Android (but apparently it is coming).

So with the above said, what is the benefits of FlashFiler over TDBF? Any old Turbo Pascal or Delphi developers here that could comment?

Regards,
  - Graeme -

[sfeinst]

I can't help you, never used FlashFiler.  But I would like to throw out how I would approach making the decision.  What doesn't TDBF do that you want or what does it do that you don't like?  Only then would I look at another technology to see if it had those items.  Even if the other technology is better, if the existing technology covers your needs, why change it (other than the fun of coding which I fully understand).

[taazz]

Hi,

I'm again revisiting the idea of porting FlashFiler to FPC, but trying to justify if it is worth it or not. The NexusDB owner offered me (at one stage) a possible license deal in porting NexusDB to FPC too.

My goal - have a database 100% compiled into the executable.

At this point I'm looking for local access only. So how does TDBF compare to FlashFiler?

* Both support local databases
* Both store a db table per file
* TDBF uses external files for indexes. Not sure what FlashFiler
does.

Flashfiler as far as remember can do both in and out of table indexes default is in table indexes.

* TDBF is local database only. FlashFiler is local and client/server.


On the other hand, NexusDB surpassed FlashFiler in features. eg: Views, Stored Procedures (which I never use), more up to date SQL syntax, and very very nice FTS (full-text search) support. I've never seen the NexusDB code, so I have no clue how "portable" it is though.

The pros for TDBF and FlashFiler is 100% free. Benefits will be easy deployment even for platforms like FreeBSD, OSX and probably even Android.

Please don't mention SQLite - I'm not interested in that. I'm also well versed on Firebird Embedded (I'm a big fan of Firebird) - and I fully know the deployment issues under OSX, and no official support for Android (but apparently it is coming).

So with the above said, what is the benefits of FlashFiler over TDBF? Any old Turbo Pascal or Delphi developers here that could comment?

Regards,
  - Graeme -

in favor of flashfiler you can also add

• SQL support.
• table encryption.
• transactions (normal and failsafe), I have no idea if they are supported in the fpc tdbf implementation.
• multi threaded server (a pain to port I guess and not strictly a plus for local storage but here it is).

I don't remember anything else at the moment I'll have to install the binaries from source forge and take a look again. Just a heads up there where a port of turbopower b-tree filer posted on the mailing list have you tried to use that as your local engine? If you do not use sql then I guess it might fit your local storage better.

[Graeme]

Thank you taazz, those are good points.  Another point Michael van Canneyt mentioned in the mailing list is that TDBF doesn't support cross-table queries, whereas FlashFiler does.

As for TurboPower B-Tree, I require SQL support, so b-tree is not an option.

[SunyD]

I ported FlashFiler to lazarus for Windows today. It is real good . I am wondering why I never used it with Delphi. 

[JD]

I ported FlashFiler to lazarus for Windows today. It is real good . I am wondering why I never used it with Delphi.

Great work. I'm interested in this. Will you make it available to the Lazarus community?

JD

[SunyD]

Yes, but first I must write the unit sqlltimst.pas and the class TExpParser for Lazarus. I took them from Delphi to port fast. I can't publish Borlands code. Look here:  http://wiki.freepascal.org/Delphi_unit_status_list

[Graeme]

Yes, but first I must write the unit sqlltimst.pas and the class TExpParser for Lazarus.

Free Pascal has had its own [excellent] TExrParser for some time now - I use it often [with FPC 2.6.4]. As for the sqltimst.pas - that sounds familiar too, and I might have written my own for the tiOPF project (available on SourceForge). FPC might already have something similar - it may be worth asking in the fpc-pascal mailing list to get some official confirmation before you duplicate efforts.

Otherwise, well done for getting FlashFiler working on Windows at least. That's a good start. I hope other platforms will follow too. ;-)  I started a port to FreeBSD, and in hindsight I probably should have started with Windows first - giving the sense of progress, because I didn't make much progress with the FreeBSD port.

[SunyD]

@Graeme:
You can port it to BSD ;-)
I will first eliminate borland code (it's a little bit in two units), then publish it and i will place all code that dependt on Windows in one unit.
After that we can port it to Linux, BSD and Mac.
I hope some people can help to port it to other platforms. It is well documented excellent piece of software. Maybe we can include it to lazarus like aggpas.  It's definitely better than TDbf and co.

I have also played with your fpgui look at this.

[Graeme]

You can port it to BSD ;-)

No problem at all. Eliminating any Borland code is definitely a high priority.

Maybe we can include it to lazarus like aggpas.  It's definitely better than TDbf and co.

I prefer to have such projects outside Lazarus's code repository. That means one can use Git (much better than SVN), which in turn allows for much easier code contributions. Plus you can have independent releases, and don't have to work at the release schedule of Lazarus itself.

I have also played with your fpgui look at this.

Wow, very nicely done!  If you haven't  yet, you must also take a look at Fred's UIDesigner mods [https://github.com/fredvs/uidesigner_ext]. I'm in the process of integrating some of his ideas into the official fpGUI UIDesigner.

[JD]

Yes, but first I must write the unit sqlltimst.pas and the class TExpParser for Lazarus. I took them from Delphi to port fast. I can't publish Borlands code. Look here:  http://wiki.freepascal.org/Delphi_unit_status_list

You're right. Keep up the good work.

JD

[HeavyUser]

I ported FlashFiler to lazarus for Windows today. It is real good . I am wondering why I never used it with Delphi.

Nice!! What did you do for the resourcestring problem?

[SunyD]

@HeavyUser:
You must define resourcestring global under implementation because fpc doesn't support local resourcestrings.
....

Sorry  guys I hadn't time to work on it. Lazarus port needs only TExprParser-Class.  It uses still some Delphi code (TExprParser from dbcommon.pas).

[HeavyUser]

I'm referi

@HeavyUser:
You must define resourcestring global under implementation because fpc doesn't support local resourcestrings.

Sorry I should have been more explicit. I mean the problem with loading the resource by number that flashfiller is using. Have you convert them all to string resources or you have extended the existing exception class to be able to load them from their numeric id.

[SunyD]

I made:
'Error code:'+ IntToStr(ExceptionCodeXY)+'  (Soner todo)';
;-)

Because  other things was importanter.