At 15:57 08-01-2002 +0000, Helen wrote:

>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.

Prior to last message, my only error report was as follows. It is a
condensed version, anticipating that the number alone would be sufficient info.

...472
Your user name and password are not defined etc.

>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?

At least 20 gdb's created by my payroll application using IBX and either
RC1 or IB6. Plus employee.gdb using IBConsole.

> >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.

OS and FB & IBO versions were stated in original post. I have now upgraded
to RC2. Does not help.

>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.

It is masterkey

> >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...

<panto on> Oh yes it is <panto off>.

> >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;

I presume you meant to say does have - because it does

>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.

Nor, for me, does RC2

> >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...)

Thanks for that

> >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.

Well, I was being a little facetious.

> >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?

Yes

>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?

FDBPath := ExtractFilePath(Application.ExeName) + 'JDC.GDB';
jdc.gdb is located in the same folder as the tutorial files.

> 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.)

All other evidence points to the contrary

>Another is that you are using a build of Firebird that doesn't work with
>IBO under some conditions. (I have RC2).

Have upgraded - same results

> 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.

There are two identical copies, one in c:\Program Files\Firebird\bin and
one in c:\Windows\System. Both are version WI-T1.0.0.679

Look - I think you must be pretty fed-up with me by now. Since you can't
duplicate the problem it would appear to be specific to my two computers. I
set out with the whole thing as I was wondering whether I should switch
from IBX to IBO and wanted to test the water. You will understand that for
me the experience has been very frustrating, but fortunately it does not
impinge on my development work which is all done with IBX. So I'm happy to
retire into my shell and call it quits.

BUT - if you think there is something lurking there which the team should
identify, then I'm willing to do the best I can to help. Just be honest.
Whatever you decide, your efforts are much appreciated.

Peter Lawson