Hi Jarvis !
Ok ! <waaah> ! So much data !!!
To be honest, the BDE isn't as bad as you are painting it. Let me examine the problems that you have presented (in the
knowledge that you have had more, but lets look at these, at least).
1 - Data loss from tables!
This is _not_ a normal occurrence. There are, to the best of my knowledge, no bugs in the BDE that are the
equivalent of the Jet Engine's ability to post one record over the top of another. Any of the items described
in #2 may also cause data loss.
2 - Clients leaving locks in place preventing tables being accessed
There are a number of ways of doing this: turn your machine off while Paradox is running; crash your machine;
break your network connection; use the Task Manager to terminate the instance of Paradox that you're running.
3 - BDE reporting out of disk space on while having n * 4Gb free space.
I do not know which version of the BDE you are using, but I would suggest an upgrade !
4 - Indexes becoming corrupt
5 - Queries not removing temporary files after use.
This I haven't seen. Do you have an example ?
6 - Queries not freeing resources after use
Have you an example I could try out, please ?
7 - Simultaneous access from two or more process leaving tables locked.
This is causable by an incorrect setup in the BDE, or by optimistic locking on a Win NT or Win 9x machine.
8 - I am a little surprised by your assertion that ODBC will be slower than BDE. Most of the claims I have heard,
admittedly from ODBC driver suppliers and ODBC component documentation, suggest that the opposite would be true.
In this case it is highly unlikely, as Paradox is a native format for the BDE. Some ODBC drivers are highly
efficient; for example, the InterBase ODBC driver is at least on a par with the SQL Links InterBase driver for
Now, what I would like to suggest.
I don't think that your worthy idea of* on to Paradox is going to fly, to be honest. This is because of the sheer
amount of data that you're playing with.
I would seriously suggest that you look at the way in which you have designed your system and see how you can move
towards a tiered architecture asap.
In this I mean that you should look to remove all dependencies on the tables being Paradox. Obviously you have also come
to the same conclusion because you are looking at ODBC; however, if you use ODBC with Paradox then Paradox hands the SQL
request off to the BDE, which then passes it on to the ODBC driver ..... so you're not losing the BDE. In addition to
this, however, a fair chunk of Paradox functionality was pushed down into the BDE at some stage; I have no idea why, but
one example is the infamous formatting problem where the instruction string "cc" has not capitalised the first letters of
all words in a string for several versions of the BDE. For Paradox 9, Corel replaced the call into the BDE with one of
its own to do the work within Paradox instead.
So, accepting that we're stuck with the existance of the BDE, let's look at what _I_ think you should do:
1. Get a copy of Paradox 9 Developer's Edition when it is released in June. This will give you a more stable platform to
develop on (than 7 or 8), a RunTime distribution system, and a copy of Borland's SQL Links.
2. If the Developer's Edition does not contain a copy of InterBase, get hold of a copy of "Local InterBase". This is a
2-user developer's version that is packaged with Enterprise Editions of Borland software. You should be able to get hold
of a copy second-hand or reasonably cheap.
3. Redevelop a portion of your system (just a little bit !), retaining Paradox as the database, but keeping a fierce eye
on the field types allowed by InterBase. Design it so that _everything_ is aliased (tables and databases), and that
tCursors are never used (certainly not for scans !). What you are trying to do is create an SQL-based piece of code that
uses Paradox for its backend.
4. Once that works, convert it to InterBase (which should be easy, but won't be, the first time, cos you'll have
forgotten lost of things <g> !). Get help from the TeamB crowd over on the Borland newsgroups, and from the CTechs on the
Corel newsgroups. Ask questions about everything !
5. Finally, look towards using Paradox as the front end for an InterBase C/S database. Then think about web access
PS No caffeine, so I'm off to kip !
-- Mike Irwin [Paradox CTech] It's not because things are hard that
[P9.00.367, V8.372, we don't dare them: it's because we don't
D9.337, W18.104.22.1688] dare them that they are hard - Seneca