Daniel,

We don't really have much to go on except some rather horrendous code that might be part of a much greater environment of horrendous code. In this message, I'm going to begin at the end and make some general comments about the ISC errors. Your code and commit problems I'll address separately.

If you are getting network errors regularly then get to the bottom of them and eliminate them. IB reports them but it knows nothing about their cause. It might be dumb users, bad hardware, dirty network traffic and it might be some bug in your application or the database (a bad UDF, for example).

The same goes for operating system level errors - I/O errors especially. You won't be able to handle them in your application code. If your application is causing them, it's a bug which you must find and fix.

At 01:07 AM 10-01-02 -0800, you wrote:

>where/how would I make sure that this commits to the database table? there
>is a CommitAction property on IBOTable1 set to caValidateCursor?

CommitAction isn't your problem. It refers to the state you want the dataset to be in after the Commit has completed. caValidateCursor is probably OK.

If Autocommit is true on your IBODatabase, then every call to Post will do a CommitRetaining, i.e. it will attempt commit all current work to the database and open a new transaction. (I'll comment more on this when I attack your code). If Autocommit is false then your transaction is under explicit control and the transaction will just run forever, committing nothing, until you call IBODatabase1.Commit.

To check whether a commit has succeeded, you can check the InTransaction property of the connection object (IBODatabase). As a self-instruction, you might like to call this after your Post calls and delete it when you have solved your problems:

procedure DataModule1.CheckMyPost;
begin
if DataModule.IBODatabase1.InTransaction then
Showmessage('Commit failed')
else
Showmessage('Commit succeeded');
end;

>the users have reported some ISC errors but I was trying to capture them,
>but don't know how to resume operation;

How you respond to a specific kind of error depends absolutely on what kind of error it is and how you want to handle it. For example, if lock conflicts are likely to be unavoidable, you will need to put every commit inside a try..except block where the except block calls Abort on the operation and then calls a pretty efficient retry handling procedure (which you can define in an Errorhandlers.pas unit and invoke from an OnErrorEvent handler in a TIB_SessionProps).

If you get a lot of key violation errors (which tend to happen in systems where users enter the data which are used to construct keys) then you are going to need a bomb-proof handler to deal with that, or do some redesigning so that users never touch keys. This is to say, either eliminate the risk of database errors, or else handle them completely.

>they get 4 errors consistently which they need to close the
>application.would this affect the post of the above records?? I dont know
>how to recover from these errors. I'm only now learning about error
>trapping, could these be the cause of my grief?

Yes: an application that has logic or other errors; not protecting code that is prone to errors or delays; overloading the system resources - these are all evident in your code.

>if yes how do I
>trap/recover from these??
>
>ISC_Error 335544344
>error while trying to open file
>to many files open
>statement Tibo internal dataset
>IBOquery2.iboqrlIBOquery2

This is an I/O error. Is IBOQuery2 attempting to do some I/O operation that never finishes? or goes into a loop?

>this one for no apparent reason;
>ISC_Error 335544345
>Lock conflict on no wait transaction
>deadlock
>STATEMENT
>TIB_statement ""
>Statement
>TIBOInternaldataset IBOTable1.IBOqrIBOTable1

This is just a normal lock conflict message. It's not an "error" - it's normal behaviour when transaction B attempts to update a record that transaction A has locked. You need to intercept this error and handle it, because transaction A will just stay unresolved if it doesn't get either committed or rolled back. Depending on circumstances, your error handler can either Abort the Commit operation and retry, or roll the transaction back. (You would do Rollback if in fact you didn't want Transaction B to get the opportunity to go in on a retry and overwrite what Transaction A did).

>this one at least once a day
>ISC_Error 335544721
>Unable to complete network request
>to host "intrbase"
>Error reading data from connection
>unknown WIN 32 Error 10054

In this case, the client application has disconnected from the server for some reason, usually a network fault or the user exiting abnormally from the application or a bad UDF or an AV or.... could be anything; but it's not something the server can help you with.

>ERROR READING wwcombobox3.item index
>WIN 32 ERROR Code 14
>Not enough storage is available to complete this operation

I'm not familiar with Infopower controls but it looks like a combobox items array has used up all the available memory or disk cache without finishing the loading of its items. Maybe you can adjust its maximum size in the control; or reduce the number of items being loaded into it. It won't be IBO-related nor directly IB-related; but if you have the application and the database both on the same physical machine and you haven't configured any temp space for the server to do sorts, the Infopower controls are probably sharing disk cache space with IB and you may have simply used up all the spare space in C:\temp.


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