I created this project because I'm missing the per record navigation and manipulation of data under managed world most of available database engine are using Dataset only fecthed from connected database using whatever query language
By using X# and Managed Dbf in VS it looks like programming in CLIPPER 5.3 C L
please don't the "Sir" here - we are all in the same boat....
You should have seen that here that there is a Vulcan RDD and that the devteam plans to write their own RDD.
RDD stays per "replaceable database driver" and was introduced by late versions of Clipper (AFAIK in v5) - and in fact it is the same record based database access like your "Managed DBF".
Hopefully earlier or later the development team will present an open source DBFCDX driver for X# - otherwise many people (including myself) will not be able to move their VO applications to the .NET platform.
[ Apology for the politeness -- can't break the habit ]
I'm aware that there is Alaska++, Apollo, Harbour and of cource Vulcan.Net that is using their own DBFCDX driver in their database engine, but I haven't tried any of those, because I'm still contended using VFP at that time.
Your news just make my day, can't wait for that release, hopefully it breaks the DBF file size limitation of 2GIG ^_^ Y
Extremely interesting indeed! Do you have it available for download, or is it still under development? I'd love to give it some test to see how well it works and additionally speed test it against the current vulcan RDD
Btw, not sure if you know it, but X# also has a Clipper-compatible preprocessor, so you can even use USE, SET ORDER etc commands as well, it's just a matter of creating appropriate #command statements.
Managed Dbf is still under heavy development since I'm the only one developing the project, my own index file (ZDX) is still buggy incomplete and currently trying to replace it with a new one, but I'm already using this in production mode if my requirements doesn't need ordering or index file.
Chris I'm pretty sure it has no match to Vulcan RDD if using an index file but gathering records using LINQ without an index file I'm not sure but I'm hoping MDbf will be faster ( crossing my fingers ).
I'm very new X# and that news regarding the Clipper-compatible preprocessor is really really exiting, I believe there's no need to continue this project if X# has it's own BDFCDX engine out of the box and breaks the 2GIG table file size limitation.
That is really exiting and I think X# is the real future of xBase! the only lacking I think is some blogging tutorials and youtube X# introduction and video tutorials, I search youtube regarding X# but without a luck T_T
You can copy/paste it in a X# app and use it like this:
FUNCTION Start() AS VOID
USE "C:\dbf\customer.dbf" VIA "DBFCDX" ALIAS test
FUNCTION DBUseArea(lNew AS LOGIC, cRdd AS STRING, cFileName AS STRING , cAlias AS STRING , lShared AS LOGIC , lReadOnly AS LOGIC) AS LOGIC
? lNew , cRdd , cFileName , cAlias , lShared , lReadOnly
it translates to a call to DBUseArea(), because that's what VO uses for (non-OOP) dbf access, but you can change it to translate into code calling your classes if you want.
I think all features of the Clipper preprocessor are now supported by X#.
I managed to extend the 2GIG table limitation in Managed Dbf and the TABLE is still compatible to VFP and the locking scheme is still also compatible to VFP and Managed DBF side to side as long as the table size is less than 2GIG both VFP and Managed DBF comply with Locking scheme.
The compatibility will only break if the TABLE is beyond 2GIG and Managed DBf can only use it and others will report it as not a Dbf file.
If you want to take a look on how I did it, the pleasure is mine to prepare a white paper source code and can give it you, both records accessing and locking scheme beyond 2GIG that is still compatible to others using the table with less than 2GIG of file size ^_^y
"This is one main reason IMO others are jumping to different Database in early 2000's+ because the DBF is only bound to 2GIG in file size on most DBFCDX engine"