I concur with Alan's evaluation that IBO is the best of the Delphi
connectivity tools out there - it was the only Firebird connectivity
tool that I tested that was able to actually complete my test cases.

However, you will need to design your data model before you get too
married to any particular platform. A good data model will allow rapid
access to any piece of data, allow for future extensions without
requiring application code changes, and minimize duplicated
information.

Be aware of the subtle differences between locking databases and
generational databases like Firebird, and the implications of the latter
(where this list comes in). Be aware that the ISAM programming model
(BDE) does not apply to RDBMS's. There is a conceptual leap to make.

Never use TTable components. Never use TTable components. Never use
TTable components.

Pay attention to local laws governing such systems. In the US,
inventory are governed by Sarbanes-Oxley. In other countries Generally
accepted accounting principles (GAAP) may apply.

Data migration is fraught with pitfalls. Check out the Maximo Users
Group web page. That application is a solid, mature boxed system that
does what you are wanting to write (too expensive IMHO), yet over 50% of
migrations to their product fail. Migration is not technically hard,
but it is often difficult from a business processes perspective.

Performance critical distributed apps should be prepared to batch and
forward, and spawn worker processes into extra threads, to maintain a
high level of responsiveness for the end user.

Pick up the book "Bitter java". As you read it, everywhere the author
says "Java", substitute "Delphi".

Check out the overbyte TWsocket and midware suites.

Keep your business logic separate from your forms.

Pickup dUnit from sourceforge. Code specifications into test scenarios,
make sure that they fail, then code the application to make the test
case succeed. At the end, you will have solid, tested, and re-testable
code. It will actually take you less time to write.

Did I say "Never use TTable components" yet? By now I am sure you get
the point.

Good luck!

On Wed, 2005-06-08 at 09:00 +0000, mbarnhizer wrote:
> Hello,
>
> I do not have a lot of experience with writing Database programs and
> have recently been giving the challange of creating one for a company
> that sells auto parts. They have roughly 8,000 different pieces to
> keep track of, along with other things.
>
> They currently have a program, but it doesn't control the stock the
> way they want it to. They want me to write a program that can
> provide all of the functions they are needing. I said "great, lets
> get started".
>
> My plan is to use Dephli with Firebird.
>
> My questions are:
>
> Where do I start? I believe Dephli needs to have the database
> already built, therefore I need to provide delphi with a database
> with all of the information.
>
> If I can export their existing database information (Names, part
> numbers and descriptions, etc) from their existing DB, can I do this
> with Firebird?
>
> Does Firebird have a way to create a database or is it just the
> engine that runs and supports a database? I have been reading about
> Firebird, but don't really see how it can create a database.
>
> I believe that if I have a Firebird database and use Firebird client
> and server applications that this will work. Question is, what is
> the best way to approach this task?
>
> Any advice or ideas would be greatly appreciated.
>
> Thanks for your time.......mike
>
>
>
>
>
>
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Visit http://firebird.sourceforge.net and click the Resources item
> on the main (top) menu. Try Knowledgebase and FAQ links !
>
> Also search the knowledgebases at http://www.ibphoenix.com
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Yahoo! Groups Links
>
>
>
>
>
>