Jeremy wrote: > I too develped using the ElevateDB predecessor, that was, > until I tried to use it in a client server arrangment, and > THEN it all turned to POOH !!! > It had SERIOUS issues with indexing, and in some cases, it > would transfer around the entire table to update just ONE field ! > It was at that point I went back to Faithfull old Access, but > I use the Titan native access Access controls, although now > we are looking at moving over to MS SQL 2005 Express, I need > to convert them over to ADO, but thats another story :-)
Yeah. The DBISAM codebase was umm... an interesting exercise in code duplication and lack of refactoring - seeing largely the same btree traversal code replicated in 8 different methods put me right off. And their initial approach to server-isation appeared to be a fairly brute force RPC insertion - i.e. pick a somewhat arbitrary point to divide the code between client and server and whack in an RPC call to transfer the call to the server without changing any of the algorithmic design. Yuck! That's the _least_ amount of work possible to claim a client/server but leaves you with significant performance 'issues' due to unwanted round-trips and nasty bandwidth issues that you really need to refactor your codebase properly to offload the work appropriately. That killed all interest in DBISAM for me - way to amateurish in it's implementation. And to fix that, they'd probably have to rearchitect large parts of the engine - which is probably what ElevateDB actually is.... Hopefully. I'd rather stick with a team that has a track record for designing client/server DB engines properly - there are plenty to take your pick from. And some of them are open source. TTFN, Paul. _______________________________________________ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe
