Helen,

Thank you for this thorough discussion. I'll keep the notes since I have
to do this in various ways (vpn, local network, direct) This will be a
good checklist to make sure I've tried everything.

I did finally get it to work with FB 1.5 and localhost with RDT on the
local network. Next test will be with RDT over VPN.

Thanks again,

Kyle

----- Original Message -----
Subject: Re: [firebird-support] 2.01 no default SYSDBA
From: "Helen Borrie" <helebor@...>
Date: Wed, May 23, 2007 18:23







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/incompati
bilities 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