At 10:53 AM 08-01-02 +0200, Peter Lawson wrote:

>ISC ERROR CODE 335544472
>ISC ERROR MESSAGE
>Your user name and password are not defined. Ask your database
>administrator to set up an Interbase login.

This is not the error you described in your last message.
This is just the normal message you get when you give a user name and password that has no match in isc4.gdb. Are you able to log in to *any* database on this server using SYSDBA and masterkey?

>>Anyway...as requested -
>>
>>I did (I think) exactly what you did: I substituted this for the first
>>line in the FormCreate:
>>
>> FDBPath := 'e:\FooledYa\murphy.gdb';
>>
>>All went fine, no errors.
>
>Pity. I copied a file jdc.gdb, created by a client (totally different
>computer and IB 6.01), into the working folder and changed 'TUTORIAL' to
>'JDC'. Same problem.

Obviously. If the user name and password don't work with one database, they won't work with any. User names and passwords are defined on the server, not in databases.

>Remember I am running FB RC1 - you presumably RC2. I suppose before taking
>up any more of your time I should upgrade.

No, I don't think you mentioned you are running RC1. This could account for at least part of your problem.

I asked:

>>Are you certain your SYSDBA password is 'masterkey' and not 'MASTERKEY' or
>>some other thing?
>
>But as I understand it (perhaps this is the problem) these parameters are
>set correctly in the code.

I think you misunderstand my question. The code sets the SYSDBA password to 'masterkey', along with a comment advising you to change it if is different on your server. If it is 'MASTERKEY' on your server, then the code needs to set it to that.

>I copied the exe and data files to my other computer, which is still
>running IB 6. Ran it there - same result.

So therefore 'masterkey' is not the SYSDBA password on your other computer either...

>Then I thought I'd experiment with opening the files with IB_WISQL ( dated
>6 Dec 200) and IB_SQL (version 4.2.6.2). The latter is associated directly
>with the gdb extension so I navigated to c:\Program Files\Common
>Files\Borland Shared\Data and clicked on employee.gdb. IB_SQL apparently
>could not handle the spaces in the path so was completely unable to locate
>the file.

IB_SQL does not have such a problem; but its Find File dialog is pretty flukey. It takes several selections to actually get a database file showing up in the tree so that you can select it. The simplest thing is just to enter the whole path into the Database field of the Connection page.

>(IB_WISQL does not have this problem)
>
>Copied the employee.gdb file up to the root and tried again. Got message
>within IB_SQL containing the following:
>ISC ERROR CODE: 335544344
>ISC ERROR MESSAGE
>I/O error for file "c:\employee.gdb"
>Error while trying to access file
>The handle is invalid.

OK, now you are seeing a problem that arose from a feature that was implemented in RC 1 to solve the "Windows path anomaly bug" (you can read about it in the Firebird 1 release notes). That manifested itself as a bug to IBO connections that attempted to open a connection that set Forced Writes on (or connecting to a database that has Forced Writes enabled using the IB_Connection's dbpDefault setting for the Forced Writes...or something along those lines).

The short answer is - RC 1 doesn't work with IBO.

>Having issued this message, IB_SQL refused to let me exit the program and
>the 3-fingered salute had to be brought into play.

OK, for future reference, in this situation, you need to go to the Transaction tab of IB_SQL and roll back the transaction that it started for the connect. Then you will be able to exit by simply closing the form as usual. (IBO won't let you escape without tidying up your transactions...)

>Repeated process with IB_WISQL. Identical result.

Identical reason.

>So one would conclude that for whatever reason my computer does not like
>IBObjects.

I would not conclude that your computer had any feelings one way or the other. You have something mystical in your configuration, for sure, and your computer is simply too dumb to guess.

>Yet doubleclick on jdc.gdb in the explorer, IB_SQL is fired up
>and so far as I can see works perfectly.

Now you've lost me. Do you mean you have the .gdb extension associated with IB_SQL? And IB_SQL connected successfully to it? Then, for sure, you have something wrong with your connection string in the Tutorial1 app at least, if not elsewhere as well.

You mentioned in one email or another that you made the connection string Fullpath\jdd.gdb. I assumed this was just a shorthand. What was the *actual* connection path that you hard-coded into Tutorial1? Could you copy/paste it into your reply, please?

From what I can see you have two, possibly three problems that I don't have here.

One is that your servers don't have 'masterkey' as the password for SYSDBA. (Mine do, which match those which are hard-coded in the Tutorial.)
Another is that you are using a build of Firebird that doesn't work with IBO under some conditions. (I have RC2).
Another is that you possibly have mismatches between gds32.dll and the servers you are trying to connect to. (I have multiple versions of gds32.dll but I have them distinctly named and my applications know which version of the client they are supposed to load.) Check the version string on gds32.dll in your system directory, see which server it belongs to, and which version.


regards,
Helen Borrie (TeamIBO Support)

** Please don't email your support questions privately **
Ask on the list and everyone benefits
Don't forget the IB Objects online FAQ - link from any page at www.ibobjects.com