[REBOL] Re: DBF
From: petr:krenzelok:trz:cz at: 1-Nov-2001 20:54
Tim Johnson wrote:
>On Thu, Nov 01, 2001 at 07:57:58PM +0100, [rebolek--seznam--cz] wrote:
>
>>Hello,
>>
>>is there some DBF reader or parser or something like that?
>>
>Hello ReBolek:
>Sorry. Don't have an immediate answer for that one... I bet
>that you will get some answers soon though.
>
>If you don't - that's one I actually need to work up
>myself - and I was planning on doing so by following
>"C" code that I have used a long time ago .......
>
>>Thanks, ReBolek
>>
>I'm curious... If (and only if) it is appropriate, may
>you tell us why the need to read DBF with rebol?
>
>Mine needs would have to do with data imported in and out of
>MS-Access.
>
MS-Access is crap :-)
Well, .dbf format is database format I grow up with. Starting with DBASE
II many years ago, switching to Clipper (I am glad for it, as MS FoxPro
is/was child's toy back at that time, while Clipper offered powerfull
preprocessor, code block evaluation, RDD - replaceable database drivers,
later also replaceable gui drivers, but Clipper 5.3 was dead end, and
Computer Associates just wanted users to migrate to Windows Visual
Objects - that's the product we use here)
native index format for .dbf was .NTX It was not powerfull enough, so
there were also other index format. E.g. native FoxPro - .cdx - the most
used one, or also SixDriver .NSX format. Later company behind the
SixDriver product leaved VO and released Apollo for Delphi. But there
were also othe companies and index format, s MTX etc., etc. It was
beaufty of RDD system, and just case of one include in your app, and you
could switch to much more powerfull solution. Shame on MS, shame on
FoxPro! It's a crap from designer's pov.
I have full .DBF header description, so you could build native Rebol
driver. I was looking into it. But you will have to solve many
incompatibilities between various formats. I already looked at it some
time ago. I think it is not worth the effort. If you can, buy yourself
/Pro license, and go with some libraries. But then of course you lose
cross-platform compatibility. There should be no problem of getting odbc
drivers for dbf, but then we are talking 350 USD /Command price level.
There is few tools/viewers to work with .dbf, very advanced ones. .DBF
is however supported also by Excel, and natively supported by languages
as Delphi, VO, Clipper, FoxPro, VB (IIRC, maybe indirectly), etc.
My fried once laughed at me using .dbf. Well - we have 50MB beasts here
- 128 or more collumns, 100K rows, and it still performs good enough.
However - once you want to get to shared dbase app, better forget data
integrity and speed. You will be probably better with some free or not
so expensive SQL solutions - mySQL (lacking transactions, and so not
suitable for us), or PostGres SQL.
We use Novell Netware here however, and we wanted to stick with .dbf -
as we have many supporting apps here. We found very efficient and
powerfull database server for .dbfs - it is called Advantage Databse
Server (http://www.advantagedatabase.com ), and comes from Extended
Systems (IIRC Palm wanted to buy them before they went into financial
troubles). We haven't believed success stories, such as Disney doing
some 2mil recs daily succesfully using it, but we now fully believe in
performance/price ratio ... verey good product, but of course far from
being free ...
If you still seek for Rebol native db, maybe there is some place for it,
but then - it should be one script, using clear api. But be carefull,
once you will be ready with your driver, you will want to add other and
other features, and solution will become slow, possibly buggy and
bloated, while still missing features as transaction support, etc.
So, - think before you throw months of development thru the window.
Today I would probably go with free and still improving mySQL database,
supported thru various platforms, and free DocKimbel's mysql scheme. It
will allow to concentrate on Rebol stuff, rather then reinventing the
wheel. If you want Rebol solution - stick with plain text files, or
something along the Elan's dbm engine (I don't know if it is still
available though).
Maybe something better could be thought of, but Holger mentioned some
time ago there will be new port type, suitable for
opened-file-operations. So, Holger, should ppl wait for it? (in your
port description, it was mentioned as last, not yet implemented port
type ...)
-pekr-
