All,

For anyone interested, here's an update on what I've found.

On Windows 2003, bat files which execute isql scripts will work over
Remote Desktop with FB 1.5. I needed to add "localhost" as suggested.

I have been unsuccessful at making the same bat files run against FB 2.01.

I tried most of the things Helen mentioned. I have not had time yet to
research the running of bat files over RDT from the Windows 2003 side of
things. But since the bat files _DO_ run against FB 2.0, it seems it is
not solely a Windows 2003 obstacle.


I will be running 1.5 for awhile until I have time to implement another
scripting solution.

Thanks for all the help,

Kyle

----- Original Message -----
Subject: Re: [firebird-support] 2.01 no default SYSDBA
From: "Kyle Green" <kyleblm@...>
Date: Wed, May 23, 2007 19:34







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@iinet.
net.au>

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