At 02:15 PM 10/01/2003 -0800, you wrote:

> >In the first place, the logic of this is flawed. What happens if a remote
> >client user omits the Server entry? The app will try to find a local
> >server, and deliver the error you have observed.
>
>Well, that's what I'd expect. I tell my clients to leave the Server entry
>blank for a local connection, and fill it in for a remote
>connection. Wouldn't my logic be correct for that? If the remote client
>omits the Server entry, I would EXPECT it to look for a local server, and
>return an error message if the server (or database file) doesn't exist.

Although this is a red herring, in the context of the problem you reported
(and it was I who introduced it, in a private email response, in an effort
to get a picture of your connection setup) you actually have the potential
to arrive at an invalid path quite easily with your click handler:

void __fastcall TForm1::ConnectButtonClick(TObject *Sender)
{
MyDB->Path = DatabaseEdit->Text;

if (ServerEdit->Text.Trim().Length() > 0)
{
MyDB->Server = ServerEdit->Text;
MyDB->Protocol = cpTCP_IP;
}
else
{
MyDB->Server = "";
MyDB->Protocol = cpLocal;
}

MyDB->Connected = true;

if (MyDB->Connected)
Application->MessageBox("Success.","Success.",MB_OK);
}

Your DFM shows that you start out here with the TIBODatabase default
(cpLocal) so (all other things being equal) the net effect of your click
handler would be almost the same as if you checked only the Server property
and set the Protocol to cpTCP_IP if the trimmed editbox string was non-empty.

I say "almost" because, by passing the unmodified user entry through to the
Server property you do not prevent a string like 'MyServer '.

So, red herring aside, we now move to the non-default properties in your DFM.

> object MyDB: TIBODatabase
> AliasName = 'Main'
> LoginPrompt = True
> DatabaseName = 'SMRDBS_MAN'
> Left = 96
> Top = 384
> end

By using the AliasName property here - which, btw, I do NOT recommend - you
open a door for yet another connection path string to be submitted. The
AliasName property is borrowed from the BDE components but it doesn't do
the same stuff that it does in the VCL. It actually looks for an
IDAPI32.cfg file and, if it finds a matching alias there, it copies the
server path details from it and uses those to work out the connection
details - protocol, server and path. As this happens as part of the
BeforeConnect processing, a "hit" on an alias will override whatever you
did in your click handler.

Getting back to the problem you originally reported, viz.

> This is on XP. I haven't tried it on other versions of Windows. If you
> log onto as an administrator, you can log on fine. If you long on as a
> Windows user that is a "Limited User", rather than an Administrator, you
> can not. The error received is simply "Cannot open file".

> I put some debugging error messages in my code, and narrowed it down to the
> following line (TheDB is a TIBODatabase):
> TheDB->Connected = true;

The error itself is not a database error, it's a filesystem error. I
suspect the application is asking the filesystem to open IDAPI
configuration file. The file must be present on your user's system, as
well as your own, i.e. you both have the BDE installed, otherwise the
message would be "File not found". But the non-Administrator user does not
have permissions for the file, hence the OS is telling you it can't open
the file.

So, to test this theory, try nil-ing out the AliasName and compiling your
test code again.

To satisfy academic curiosity, may I suggest that you read the IBO4 help
text for this property and for AliasParams and, possibly, before you take
it out, stick some messageboxes to display the run-time values of these
properties at the point where you see the error message.

cheers,
Helen