NightspeedIT wrote:

Hi Derek,

That is still not much information to go on for an analysis. This error
is usually preceded by another error message indicating the real cause
of the problem. The transaction handle error means that the transaction
context has (for some reason) been lost or not correctly established
before attempting to perform an operation requiring that transaction
context. Here is the documentation for this error message...

-------
BAD_TRANS_HANDLE, invalid transaction handle

Explanation: You may have attempted a commit or rollback operation
when no transaction is active. For example, your
program may execute the same set of actions to handle
all fatal errors. If those actions include a rollback
operation, the rollback operation will generate the
BAD_TRANS_HANDLE error after a fatal error occurs on
database attachment or on an attempt to start a
transaction. The BAD_TRANS_HANDLE error occurs because
you cannot end a transaction when no transaction has
been started.

(RCI and RDML users) If you declared a variable as an
explicit transaction handle, you: a) may not have set
the variable to zero before starting the transaction or
b) may have modified the variable after it was set by
the database system.

User Action: Do not execute commit or rollback operations when a
transaction is not active. Alternatively, you may
choose to specifically check for this error after
execution of commit and rollback operations, and branch
to program recovery actions when appropriate.
(RCI and RDML users) If you explicitly declared a
transaction handle variable in your program, set the
variable to zero before referring to it. Make sure
that your program does not write to this variable after
initializing its value.
------------


Maybe you could describe more what was being done, and how, at the time
of the error? Where do you see the error (application screen or log
file)? What tools or languages are being used by the application? You
should probably check for dump or log files at the application
directory, the user directory, the user's SYS$SCRATCH directory or at
the directory pointed to by the logical RDMicrosoftBUGCHECK_DIR.

Eventually, a successful analysis may require a qualified person with
access to the code and a system that is producing the error.

I think (especially if you were offering money) you were probably
talking to the wrong people at Oracle. I would suggest contacting one of
the persons listed at the following web page...
http://www.oracle.com/technology/pro...cts/index.html
Ingrid Klein should be able to help you get in contact with a qualified
person in Oracle Support.

There are also several Rdb Consultants worldwide who would be happy to
have your business...

achi Informatik Dienstleistungen - Switzerland
http://www.achi.ch/

ACS - operations in nearly 100 countries worldwide
http://www.acs-inc.com/

ALI/Empirical Software - USA
http://www.aliconsultants.com/

Bethinda - Netherlands
http://www.bethinda.nl/en/index.html

BIOS Software GmbH - Germany
http://www.bios-software.de/bios/index.htm

Colin Sewell OpenVMS Consulting Services - Canada
http://www3.telus.net/csewell/

Contemporary Technologies - USA
http://www.contemptech.com/

DCU - Data Collections Unlimited, Inc. - USA
http://www.dcu-inc.com/

Equicon - Germany
http://www.equicon.de/

Evenlogic, Software House, South West London, England
http://www.evenlogic.co.uk/index.html

First DBA Source, Inc. - USA
http://www.firstdbasource.com/

GAP - UK
http://www.gap.co.uk/
http://www.gap.co.uk/oracle_RDB.html

ITurnITy Information Group - Netherlands
http://www.iturnity.com/index_uk.htm

JCC Consulting, Inc. - USA
http://www.jcc.com/

Keane, Inc. - India Subsidiary
http://www.keane.com/about/worldwide...&country=India

M Squared Consulting, Inc. - USA - ALL-IN-1, TeamLinks, Linkworks,
Pathworks, Rdb - Partner Brief
http://www.openvms.compaq.com/partne...ared/index.htm

MainTrend Ltd. - USA and Canada
http://www.maintrend.net/

Meyering Software Productions b.v. - Netherlands
http://www.mspbv.nl/msp_index.htm

Praxa Ltd - Australia
http://www.praxa.com.au/

RKS - Sweden
http://www.rks.se

Salem Automation - USA and Puerto Rico
http://www.winvms.com/about.html

SCI - USA
http://www.sciinc.com/

SEKA-Service-Programing - Germany
http://www.seka.de/e/service/Program...Programmierung

SIT System- und Informations-Technik GmbH - Germany
http://www.sit-germany.de/indexen.html

Softax - Poland
http://www.softax.pl

STI - Soluções em Tecnologia da Informação - Brazil
http://www.stinfo.com.br/

TE&PJ Contractors - New Zealand
http://www.jerrom.co.nz/

VX Company - Netherlands
http://www.vxcompany.nl/

Yartoo Software - Australia
http://www.yartoo.com.au/

There are probably many others which I don't have listed.

You may also consider joining the JCC Rdb Listserver discussion and
informal support group. Instruction for joining are at...
http://www.jcc.com/listserver.htm


Cheers!

Keith Cayemberg

Hi,

What's the big deal? Surely with those outdated versions and no support
contract, this system can't be doing anything important. Can it? What does
Nightspeed do? Do they have any customers or shareholders that read this
group :-(

Ok, sorry to be a pain and now I'll try to help. But it just drives me nuts
how many other companies out there just like yours (and some of them are
VERY big and profitable) are too cheap to supply the resource levels
required. (And the number of Rdb bodies out on the street.) Insurance eh,
who needs it?

Anyway, you say nothing's changed so without much information to go on, I'll
offer two guesses FWTW

1) You've started to get a lot of deadlocks (any other errors logged to user
screens etc?) maybe a sorted index is looking a bit crappy after years of
neglect. If your error-handling code is rolling back the transaction so as
to recover from the deadlock then maybe the code is incorrectly proceeding
to the otherwise legitimate commit/rollback.

2) Some part of the database has grown and the number of rows has led to an
internal array blowing up and if your transaction handles are in memory
after the array. Is the system written in Pascal, RDML, RDO? Do you declare
your own transaction handles? Sadly, I have seen production systems where
people simply ignore this error :-( Often, they're using a specific database
handle in one module but accepting the default rdb$dbhandle in the other.
Then they say "That module does what we want let's call that" and they end
up with two attaches to the database each with it's own transaction context.
So a transaction could be started in one attach and you're trying to commit
it in another. Are you using SQL Connections?

Any more information? How many times does RMU say each user is attached to
the database? Is it only one specific module/option?

Regards Richard Maher

"NightspeedIT" <derek.cowdrey (AT) nightspeed (DOT) com> wrote