David asked: > why did you feel the need to write your own database engine,
Why do we have our own database? Partly, it's a historical thing. Accredo is essentially a sucessor to our Profax applications which have a 25 year history. So initially, we had to have our own database back in the PC/XT DOS 1.0 dual floppy days. I know the database intimately, and we can address all the data corruption causing bugs that MS kept introducing in Win9x and again in Win2K when they rewrote the network redirector again, without waiting on some 3rd party database vendor. Profax and Accredo have a hard-earned reputation for reliability of data, even in some quite 'hostile' environments - our end-users are not IT people. Before things like SQL Server became more common, most of the other file based products had a repuation for ongoing file corruption and many still do based on feedback from our resellers. With our transaction processing layer and the new query processing engine, switching to a 3rd party file based engine would be a step backwards in performance and reliablity. We've had the discussion about getting out of the DB engine business a number of times (at my instigation actually :-) but it doesn't stack up. And I've actually read the DBISAM source code! Enough said. > what is the magic trick you have for supporting multiple databases, etc) Well, there is an ANSI/ISO standard for SQL stored procedures called SQL/PSM (Persistent Stored Modules) which was standardised in 1996. However, only DB2 and the new MySQL 5 beta support it, largely because they added stored procedures and triggers to their products quite late relative to the other vendors. This is why most DBAs and/or developers have never heard of it. So, if you had a complete SQL/PSM 96 engine front end which could parse and recompile your SQL statements and stored procedures into Interbase PQSL, MS T-SQL, Oracle PL/SQL, (insert SQL vendor of choice) with all the needed changes for syntax and semantics to handle the execution side identically, and this all happened on the fly (sort of a SQL babel-fish) without the developer having to do anything... :-) > P.S. If your software is "Delphi p0rn" then what does that make Max? ;-) Damn! That was a mental image I didn't need :-) Regards, Paul Heinz. _______________________________________________ Delphi mailing list [email protected] http://ns3.123.co.nz/mailman/listinfo/delphi
