Errors, any ideas

[Wilson, Fred]

No, I don't know what statement caused it, nor even, for sure what
application(s) might have kicked it off. I thought the same thing about the
file size, but what bothered me is the:
"The device does not recognize the command"
part of the message.

I think that we can reproduce this now. In need to confirm that's the case,
and, if so, I'll go in and add a bunch of tmp_dirs to the IBConfig file and
see if that's the cause of that part of the error, or perhaps the whole
thing.

One thing that's really interesting though, is, in the big realm of sites,
this is not a large database. We have sites with larger (physicall)
databases, and have yet to run into the temp file size problem

Regards,
Fred Wilson
SE, Bell+Howell
fred....@mmt.bellhowell.com

-----Original Message-----
From: Leyne, Sean [mailto:sle...@atkin.com]
Sent: Thursday, October 18, 2001 11:03 AM
To: Interbase Discusion Group
Subject: RE: Errors, any ideas

Fred,

> KHAN (Server) Thu Oct 18 10:01:08 2001
> Database: D:\INTRBASE\ATT-CHARLOTTE\CURRENT\GA
> I/O error for file "/temp/ibg00222"
> Error while trying to write to file
> The device does not recognize the command.
> sort error

To you know what statement is being executed at that time?

This looks at lot like to error message reported when the sort file
grows larger than 2Gb in size. Unfortunately, the engine code/functions
limit the size of a size sort file to 2GB - 1 byte in size.

There is a workaround to this, and Firebird has a fix which will be
included in it's next release.

--
Sean

There is nothing wrong with Interbase,
that can be fixed with Firebird.
www.FirebirdSQL.org
_______________________________________________
Interbase mailing list
Inte...@mers.com
http://mers.com/mailman/listinfo/interbase
InterBase Search Engine - http://www.mers.com/searchsite.html

[Wilson, Fred]

Long story, so I'll try to keep it short. We have some software that's been
working fine for a period of time. Someone changed on of the applications
and it has some problems, on of which is it's transaction control that
causes transaction gaps. That, in itself is not the problem. We can fix that
and are real familiar with transaction gaps. The puzzling one, is, one site
has seen this, and we just duplicated here, in house, with their database.
The applications will get:
"ISC ERROR MESSAGE: Internal gds software consistency check (can't continue
after bugcheck)"

The Interbase logs shows:

~~~~~~~~~~~~~~~~~~~
KHAN (Server) Thu Oct 18 09:52:54 2001

Database: D:\INTRBASE\ATT-CHARLOTTE\CURRENT\GA

internal gds software consistency check (pointer page vanished from
DPM_next (249))

KHAN (Server) Thu Oct 18 10:01:08 2001
Database: D:\INTRBASE\ATT-CHARLOTTE\CURRENT\GA
I/O error for file "/temp/ibg00222"
Error while trying to write to file
The device does not recognize the command.
sort error

~~~~~~~~~~~~~~~~~~

The temp area is defined as c:\temp and there is 3.1 gigs of freespace. Any
ideas ??

Regards,
Fred Wilson
SE, Bell+Howell

fred....@mmmt.bellhowell.com

[Leyne, Sean]

Fred,

> KHAN (Server) Thu Oct 18 10:01:08 2001
> Database: D:\INTRBASE\ATT-CHARLOTTE\CURRENT\GA
> I/O error for file "/temp/ibg00222"
> Error while trying to write to file
> The device does not recognize the command.
> sort error

To you know what statement is being executed at that time?

[Ann W. Harrison]

At 01:34 PM 10/18/2001 -0400, Wilson, Fred wrote:

>The applications will get:
>"ISC ERROR MESSAGE: Internal gds software consistency check (can't continue
>after bugcheck)"

That message merely means that the connection had a fatal error and
can not continue, however much it tries.

>~~~~~~~~~~~~~~~~~~~
>KHAN (Server) Thu Oct 18 09:52:54 2001

> Database: D:\INTRBASE\ATT-CHARLOTTE\CURRENT\GA

> internal gds software consistency check (pointer page vanished from
>DPM_next (249))

That suggests that something may be very wrong with the database. Is
there any chance that you've fallen into the problem of different
users passing in different name strings?

>KHAN (Server) Thu Oct 18 10:01:08 2001
> Database: D:\INTRBASE\ATT-CHARLOTTE\CURRENT\GA
> I/O error for file "/temp/ibg00222"
> Error while trying to write to file
> The device does not recognize the command.
> sort error

My guess would be that this is a secondary effect of the previous
error.

Regards,

Ann
www.ibphoenix.com
We have answers.

[Wilson, Fred]

We're double checking to make sure that the users (applications) aren't
connecting to the database via two different connection strings. We just got
some information that the site had someone, outside of us, write something
for them, so it's possible that the connection string isn't the same. Our
applications shouldn't be (but we're double checking), as the install CD
sets the connection string (via the registry) on all the clients, when the
software is installed.
BTW, the server is IB5.6, IB4.0SP5 and so are the clients. Connection to the
server is via TCP/IP. Nothing else,other than NT and IB, runs on the server.
Outside of the known connection string problem, does anyone know of any way
that a client application, running on a separate box (TCP/IP) can cause
database corruption on the server via IB API calls. Any known bugs or
"things you shouldn't do", like execute a query that returns rows and not
fetch the rows, etc..

Regards,
Fred Wilson
SE, Bell+Howell

fred....@mmt.bellhowell.com

Regards,

[Ann W. Harrison]

At 11:06 AM 10/19/2001 -0400, Wilson, Fred wrote:

>Outside of the known connection string problem, does anyone know of any way
>that a client application, running on a separate box (TCP/IP) can cause
>database corruption on the server via IB API calls.

Yes, I suppose a UDF could do that.

> Any known bugs or
>"things you shouldn't do", like execute a query that returns rows and not
>fetch the rows, etc..

In theory no - of course we don't have access to all known bugs,
but the different name string problem is the only one I know of,
aside from shooting yourself with a UDF.