Hi

I think we've got two conflicting issues here and both need to be addressed.

1. Andre needs to find a fix or workaround to this specific problem.

2. We need to identify if there is indeed a bug in the provider and/or Firebird.

At the moment, the responses seem to be mainly aimed at point 1. But if we find a workaround by using parameterized queries or whatever, it still doesn't explain why *not* doing that causes errors in the Firebird server. That shouldn't happen. We also need to look at point 2.

Cheers,

Mike.

Oleg V. Paschenko wrote:
Hi,
 
Try to use parametrized command instead of generating new sql statement in loop.
 
I have met this before when I have assigned in loop new CommandText. It seems that the previous statements are left unprepared by Firebird. I don't know whether it is feature of Firebird or the provider. Carlos?
 
Regards, Oleg


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Andre Jager
Sent: Tuesday, November 01, 2005 5:50 PM
To: [email protected]
Subject: Re: [Firebird-net-provider] Firebird crash due to .Net provider?

I used "multiple commands". My first thought was to call the dispose as well. So I did, but it did not change the behaviour on the server side.

I will try the prepare and see if anything changes. Maybe I did not understand the on-line help and I am doing something wrong.

Another side effect is not only the rapidly increasing memory requirement of the Firebird server but as well as the 100% CPU time fbserver.exe consumes.


.
.
.
                       if (Counter > 1)
                        {
                            Command =
                                "execute procedure ADD_FIELD_SET_DATA('"+SessionId+"', '"+FieldSetName+"', '"+Header[j]+"', '" + Data + "', '"+ObjectId+"')";
                        }

                        FirebirdSql.Data.Firebird.FbCommand cm =
                            new FirebirdSql.Data.Firebird.FbCommand(
                            Command, c.Connection, t
                            );

                        cm.ExecuteNonQuery();
.
.
.


André Jager

 

Reply via email to