Chuck,

At 01:26 PM 7/01/2005 -0800, you wrote:

>Hello, Artur and Helen:
>
>Thanks for the reply.
>
>After both of your replies I really thought the problem would have been the
>absence of the MSVCRT.DLL and MSVCP60.DLL. It was something I forgot to
>check. No luck.
>
>It took a couple of days for my wife to bring back her office system for me
>to check.
>
>There are both files in her Windows/System32 directory, dated about 8/2002
>(which are later than the ones on my system).

First off, your previous posting said you were trying to deploy to the new
machine with the full server engine running, i.e. not embedded. If that's
not what you meant, then please say so.

>I use a firebird.conf which points to my data in the <<App>>/Data directory.

I don't understand what you mean here. Which parameter are you referring
to and what value is set for it?

By default, the server can access databases anywhere on the machine. The
parameter is DatabaseAccess and its default parameter is FULL. You have
two alternative configs:

NONE, which requires all database access to be via an alias defined in
alias.conf

RESTRICT, which allows connection to a path but restricts the path to be
within a specified filesystem "root".

So, to restrict ALL database access on this machine to d:\MyApp\data, you
would have this entry (remembering to delete the "#" symbol):

DatabaseAccess = d:\MyApp\data

>I have successfully deployed FB embedded with either fbclient.dll or renamed
>as gds32.dll in the same directory of my app. I tried putting gds32.dll in
>the system32 directory, still no luck. BTW, IBO has no problem with
>gds32.dll being in the same directory as the app.

Of course it doesn't have a problem with it: the app directory is the
first place it looks. After that, the %system% directory. Check your
environment variables to see which directory WinXP Home regards as the
system directory.

>It still seems to be a database recognition thing, but I don't have a clue
>what's wrong. Any further suggestions?
>(Like I said it works just fine off a read-write CD for two out of the 3
>systems. )

Have you eliminated the possibility that you unintentionally installed the
Classic server? Clients to Classic can't use IPServer (i.e. cpLocal) with
Classic. They must connect through TCP/IP local loopback
(Server=localhost, Protocol=cpTCP_IP).

>BTW, I didn't intend to throw in a red herring about the FB Guardian. I was
>just saying that in my test on my development system, I turned off access to
>the full FB so that it would be forced to use the fbclient.dll.

I have no idea what you're talking about here. Clients connect to a
database engine, not to Guardian.

>Helen, I'm not sure what you mean by having my full FB application point to
>the localhost server (TCP/IP local loopback) and not to the IPServer.

See comments about re local loopback server. Remember, too, that your
particular distro of XPHome might not have localhost defined (it didn't, in
a machine that I set up for my husband). You'll have to find the HOSTS
file and make an entry for it, viz.

127.0.0.1 localhost

If you can't find HOSTS, then find hosts.SAM, copy it and rename the copy
to HOSTS. All of these details are in the Quick Start Guide, which you can
download from the Firebird website.

>I've never did anything special about this, since the app is essentially a
>non-networked, desktop system. Where do I look to make these changes and
>why bother?

Because the IPServer (cpLocal) as it is currently implemented is not
recommended for production use, especially where multiple connections (by
one or multiple instances of the same app, or different apps, or where
events are being used). For embedded, IPServer has its specialised
use. Otherwise, you should treat cpLocal as "for development use only".

>Thanks again, please consider other possible reasons for the problem, ok?

Sure, but do clarify that you really mean you are trying to deploy your app
for use with the full server installation and not embedded. And which
server you actually have running, of course.

./hb