At 06:26 AM 24/05/2007, you wrote:

>Hello,
>
>I am still pursuing this problem on a WIndows 2003 server.
>
>I removed all evidence of a previous FB 1.5 install
>I had previously uninstalled, but now I have deleted the remaining
>Firebird_1_5 folder.
>
>I also uninstalled 2.01, and deleted its folder.
>
>Next I reinstalled 2.01, and everything looked normal. When I run my
>standard create database script via a bat file:
>
>CREATE DATABASE 'd:\db\fb\Data\MyDb\MyDb.fdb' USER 'SYSDBA' PASSWORD
>'masterke';
>
>
>I get an error that the account does not exist:
>
>
>D:\dbRoot\Projects\SqlScripts\Fb\Bat>
>"c:\Program Files\firebird\firebird_2_0\bin\isql.exe" -user 'SYSDBA'
>-password 'masterkey' -input ..\Create\DbCreate.sql -echo -output
>..\OutFile\RecreateDatabase.out.txt
>Use CONNECT or CREATE DATABASE to specify a database
>Statement failed, SQLCODE = -902
>Your user name and password are not defined. Ask your database
>administrator to set up a Firebird login.
>After line 0 in file ..\Create\DbCreate.sql
>
>Is this a bogus error message?

No, it's a message of several indications. The sysdba __account__
exists (unless you removed it). The message means that the wrong
password (or no password) is reaching the interface. It can also
mean that the bat file doesn't have authority to access the security
database, or that there is a security database in its access path
that is not the one it should be seeing.

>Is there some other problem?
>
>I am running the bat file and script over VPN and Remote Desktop.

The problem has to be there, whereby the shell that the bat file is
running in is not local. One way or another, the bat file can't
access the security database, as it must do, in order to connect to
(or create and connect to) a database.

Elsewhere you established that you can perform a local login from the
command line. This could only work if that command shell was not
running as an RDT client (or, indeed, if your command shell had
access to the ISC_USER and ISC_PASSWORD variables...)

To use the new XNET IPC protocol on S2003, the IPC name needs to be
made globally visible via the IpcName parameter in
firebird.conf. Depending on how the server is configured, your batch
file might succeed if you try the following:

Uncomment the default entry (IpcName = FIREBIRD) and add the prefix
Global\ to it. As the prefix is case-sensitive, it should be exactly
Global\FIREBIRD. You will need to restart the server to make it visible.

Another thing that changed with v.2.0.x is that admin-level services
can now be accessed only via the Services Manager. By some sleight
of hand in the new WNET IPC protocol, that is available to an IPC
connection that is made from a non-remote command shell. If the
server machine considers the connection to be remote (as could well
be the case with your VPN client) then the connection must be made
via the network. If exposing the IpcName globally doesn't do the
trick for the batch file's shell then you can deduce that S2003 isn't
allowing that shell local access.

On the Windows side, using "localhost" as your server is no good for
a RDT connection, either. You would have to supply the actual
hostname of the server.

If you find you need to explore down this path, start with a sample
script where you hard-code the server's hostname into the path, e.g.

For TCP/IP:
CREATE DATABASE 'MyHostName:d:\db\fb\Data\MyDb\MyDb.fdb' USER
'SYSDBA' PASSWORD 'masterke';

For WNET:
CREATE DATABASE '\\MyHostName\d:\db\fb\Data\MyDb\MyDb.fdb' USER
'SYSDBA' PASSWORD 'masterke';

If that works out, then you'll need to find a way for your batch
files to retrieve the hostname. I seem to recollect that there is an
environment variable but, if not, then you could possible store it in
a file near at hand and have the batch file read it into a local variable.

>This is obvioulsy a showstopper. It was a normal straightforward install
>as far as I can tell.

If you have eliminated all the possibilities of
conflicts/incompatibilities with previous installations then it can
ONLY be a configuration problem. It could be worthwhile browsing
MSDN to find out what things affect batch file execution on
S2003 that weren't around in other Windows versions.

Other configuration things that I've probably missed along this track are:

1. Did you perform the security database upgrade and test that it
was working? (I know I raised this earlier in the thread but I didn't
see an answer to it)

2. Did you remove the ISC_USER, ISC_PASSWORD and FIREBIRD
environment variables from everywhere? (both global and user-specific)?

3. Did you delete the v.1.5 keys from the Registry? (Someone else
suggested this but, again, I never saw the answer...)

./heLen