At 07:18 PM 1/04/2003 +0530, you wrote:

><not relevant to the discussion>
>This was one of those "fools rush in where angels fear to tread" projects
>I was a VB/SQLServer programmer and suddenly switched to Delphi and Firebird.

It's relevant, believe me.

>So No Holds Barred comments are welcome.
>I have been lurking on this list for a long time and really appreciate the
>efforts that somebody like Helen puts in answering silly questions. This
>kind of sharing of information is something that I really admire.

However, there are limits.
You could do yourself a lot of good by getting hold of a good third-party
book on Delphi. Don't take that as sarcasm. Delphi is VERY different to
VB, not just at the surface level of the language.

Now, to try and reduce the noise in this thread, I'm going to mention some
things that are relevant to what you are doing here. This message is too
rambly for me to spend the hours necessary on addressing it. Let's just
look at the AV problem. In future, when you have your architecture cleaned
up, you can then ask specific questions. It makes it easier for people to
help.

1. You drew my attention to a call to Application.Terminate (I didn't
notice that in the first posting). Don't do it. You can *read*
Application properties from within the app but you should never call its
methods anywhere but in the DPR. And never call Terminate. So, if that
exception block is ever executed, there's going to be an AV. (For
Application.Terminate, read "Application.CrashMe"). Read up in the Delphi
help on the concept of object ownership.

To close a Delphi app, you get to the position where you can close the main
form. At that point, closing the main form causes the form to clean up the
objects which it owns and then the application object proceeds to clean up
globally and, finally, to terminate. It's very likely that you have
undestroyed objects accumulating all over the place ( = memory leaks) if
your code reaches this block.

The main "form" is the first form or datamodule that is created by the
application. You will get AVs at run-time if you add forms or
datamodules to your project AFTER the default form and then do stuff on a
higher-up form that depends on the existence of the lower-down one. You
need to reorganise the Application.CreateForm() calls manually; and you
need to remove the calls that create forms which your application creates
in run-time.

On the subject of the Users property of TIB_Connection and its descendants,
the warning in the IBO help (we now know) applies to buggy versions of
gds32.dll from IB 5.x and InterBase 6. It was fixed in Firebird long ago.

Still on the subject of gds32.dll, you have a potential source of server
crash if you have a mismatch between the version of gds32.dll and the
version of the server. If that's cool, then there is no guarantee that the
IBX Service components will work with the Firebird client; and if you are
using the IBX that came with Delphi 5 then you are water-skiing without a
boat.

If you DO need to use a service component, try one of the ones listed in
the Contributed Code section - bdslib or Lorenzo Mengoni's components. You
won't then need a separate database connection for server-level stuff,
which is another highly-probably cause for the server crash.

And - above all - if you have users trying to use Windows local connection,
then you will have all sorts of problems with it using your current
setup. Use TCP/IP always - even on a stand-alone setup. You can safely
use a Win local connection for an admin app that is meant to run only on
the server by SYSDBA with exclusive access.

And now to bed...

Helen