I have problems with paths to the database when I use Firebird Embedded
Fast, flexible and high-performance component library for Delphi, C++ Builder and Kylix intended for work with InterBase and Firebird using Direct InterBase API.
|
Question:
I have problems with paths to the database when I use Firebird Embedded
at run-time and Firebird at design-time. Can you give me some advice?
Answer:
We have consulted with Dmitry Emanov about Firebird Embedded and now
we can tell you about possible problems with it.
1. You can not use Firebird or Yaffil Embedded in the debug-mode. The
debug-mode
allows a single connection to a database; when you try to navigate
through your application step-by-step using Delphi debugger it
tries to create two connections.
2. If you use related paths to a database (without absolute
paths) at design-time you can not be sure that Delphi IDE considers
a directory with your current project as default. That's why
Firebird (and Yaffil) Embedded sometimes can not find your database
file.
Dmitry Emanov recommends to use Firebird SS for development
and Firebird Embeddded for distribution. Since the embedded server exclusively locks the database file, it's impossible to access a
database from different applications using fbembed.dll. That's
exactly the case with Delphi, if your datasets are open in
the design-mode and you're running your application under debugger.
Just small correction - the embedded server does support multiple
connections if they're being established from the single parent process (in different threads).
We are a small software company with thousands of customers delivering comany wide systems including accounting, logistics, e-commerce, POS, sales etc etc. Several years ago, when we were still a very small company, we used Delphi 3 and Paradox combined with BDE. As our system (and customer base) grew I decided to switch to Delphi 5 and Interbase. Being a huge improvement over Delphi 3 and Paradox, I encountered numerous problems with IBX: memory leaks, performance issues and other problems. Borland was not to be bothered: IBX was provided "as is" and no support was avaliable. Not being very eager to use third party components with Delphi at first, I decided to give FIBPlus a try. At once all problems where gone: no more memory leaks and performance was very consistent.
But the real advantage of switching to FIBPlus came with the upgrade to D2005: after upgrading there were some problems with the new FIBPlus version. After emailing the problem I received an update within an hour! And this was at 11 pm! A few other (smaller) errors where handled in the same way.
Our motto is: software is as good as its support. And support of Devrace is just great!
Just a little indication of our FIBPlus use: all our software runs 100% on FIBPlus. Our customers have a total of aprox. 4.800 Firebird databases in production, with a combined size of over 130TB and over 80 million transactions a day. Every
day. And FIBPlus has not failed a single transaction. Not once. There is, however, one (minor) drawback in using FIBPlus: while debugging an application which uses and invalid SQL instruction, de Delphi Debugger returns to the FIBPlus code instead of to our calling code (where the actual error comes from), thereby complicating de debug proces a little. But that is a very small price to pay for a otherwise brilliant third party solution! >>
Bas Jordans JorSoft Ltd
