If the investigation into this produces a bug, i.e. badly written client
code can corrupt a DB, then it is going to be important to trace. Never
calling a commit / rollback should never cause a problem, happens all the
time when apps die.

What language is the app written in?
What OS?
How complicated?

If it's Delphi & API Direct, I'ld be more than happy to take a look in my
spare time. Although I would imaging business specific confidentiality
maybe a problem for you and I might take a while to get the "spare" time.

Anyway, don't get rid of the version that breaks IB, not even to change the
connection string.

Good Luck,

JAC

""Wilson, Fred"" <fred.wilson@...> wrote in message
news:E9E4431A916AD21191FD00104B986AEFC238C9@......

> Yup, we've been able to repeat it "on demand".. We haven't looked deeply
> into it to see what happens to the application (it's only one of 'em) when
> it "goes west", but we know how to provoke it and we know that there was
> some badly written code that's in the wrapper layer around the API

interface

> that was coded.
> Right now, we're trying to get a release ready to go, so we're more
> interested in getting the bug fixed (which we did) than tracing through,
> trying to find out exactly what the application did after the "incident".
> Later, I can look through the app and see what it was doing.
> What it was doing, in the Commit method, was, if the commit() failed, it

was

> setting the transaction handle to NULL. I suspect that the application
> is/was still attempting to use it somewhere. The Rollback method,

basically

> was never getting called, or I should say, would never work (after a
> Commit() failed), as one of the first checks in the Rollback() method is

to

> check for a NULL transaction handle. This, of course, produced a
> transaction gap, but, as I mentioned, we haven't followed it further to

see

> what else was going on. We fixed this bug and have now continued on,

looking

> for a couple of more things.
> Like I mentioned, the corruption is 100% reproducable.
>
> Best,
> Fred Wilson
> SE, Bell & Howell
> fred.wilson@...
>
>
>
> -----Original Message-----
> From: Jason Chapman (JAC2) [mailto:jason@...]
> Sent: Tuesday, April 02, 2002 12:41 AM
> To: ib-support@yahoogroups.com
> Subject: Re: [ib-support] Any ideas
>
>
> No ideas, but I can't see how a client can be doing this by corrupting

it's

> own memory structures. The whole point of the level of abstraction SQL
> based servers are supposed to give is that a rogue client can not corrupt
> the db.
>
> When you say you can reproduce, you mean you can take a perfectly good db
> and trash it by running your apps?
>
> What about the old chestnut of the connection string error?

(server:e:\data

> vs server: e :\data)?
>
> Cheers,
>
> JAC.
>
> ""Wilson, Fred"" <fred.wilson@...> wrote in message
> news:E9E4431A916AD21191FD00104B986AEFC238C1@......
> > IB5.6 running on W2000 (and NT4.0).
> > Client applications using the IB API directly. We obviously done (or am
> > doing) something wrong. We can reproduce the error(s) below with some
> work.
> > I suspect that the client application(s) is trashing some memory

somewhere

> > (maybe the DPB, the TPB, XSQLDA, etc).. Any ideas what, specifically,

can

> > cause the below, from the Interbase Log:
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> > BUBBA (Server) Mon Apr 01 11:29:04 2002
> > Database: D:\INTRBASE\BIN\GA
> > internal gds software consistency check (pointer page vanished from
> > DPM_next (249))
> >
> >
> > BUBBA (Server) Mon Apr 01 11:42:19 2002
> > Database: D:\INTRBASE\BIN\GA
> > internal gds software consistency check (pointer page vanished from
> > DPM_next (249))
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> > Thanks,
> >
> > Best,
> > Fred Wilson
> > SE, Bell & Howell
> > fred.wilson@...
> >
> >
> >
> > To unsubscribe from this group, send an email to:
> > ib-support-unsubscribe@egroups.com
> >
> >
> >
> > Your use of Yahoo! Groups is subject to

http://docs.yahoo.com/info/terms/

> >
> >
> >
>
>
>
>
> To unsubscribe from this group, send an email to:
> ib-support-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
> To unsubscribe from this group, send an email to:
> ib-support-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>