| Subject | Re: [firebird-support] Firebird ADO.NET: ExecuteNonQuery Returns -1 On Successful Insert |
|---|---|
| Author | |
| Post date | 2018-05-18T17:17:14Z |
Thank you Helen, for your reply to my original query regarding ADO.NET and Firebird... 
I did in fact find the Firebird .NET provider Email list after I had submitted my query here and then forwarded the same query over there.
Jiri was kind enough to respond. His reply included the information that he apparently could not provide the Records Affected by an actionable DML statement within a stored procedure in ADO.NET since the database engine did not provide that information for him to acquire it in that vein. As a result, one has to manually enter the RETURNING clause to such DML with the ROW_COUNT system variable to get such information returned to the ADO.NET provider.
Prior to this, I incorrectly stated that I saw this as a weakness in the Firebird engine, which maybe should be changed by the database development team. This was incorrect on my part as I was not considering the technical philosophy that underscores the foundations of Firebird, which I imagine was the foundations for the original Interbase in 1986.
However, I come from an extensive background with the development of database applications using SQL Server primarily. However, I have used Oracle, Sybase, and MySQL as well. All of these database engines' ADO.NET providers return a Records Affected number. As a result, after using so many different database systems over a very long career in this way, I commented that I saw this missing attribute in Firebird as a weakness instead of something akin to how Firebird is expected to process actionable DML.
That being said, I produced a technical paper a few days ago on my own technical article site that I announced on this forum, which you may have read. This article was designed with the intention of attracting other .NET development professionals who have similar backgrounds to mine by describing the inconsistencies they will find with Firebird when working with a db-manager as well as ADO.NET. And such professionals with my type of background will see a number of issues with Firebird that will not be seen as expected database behavior. I hope that my paper will assist such professionals in understanding Firebird by demonstrating these inconsistencies while also providing them with the appropriate solutions to work with them in a manner that will make them more comfortable with this database engine.
Nonetheless, it is my contention that such issues viewed as inconsistencies are a factor in Firebird's lack of similar popularity in the States when compared to the other major systems commonly used. Despite this, a recent poll of database usage shows Firebird slowly moving up the popularity indices. And yet, there is nothing that I can see that should prevent Firebird from being a serious consideration for database organizations that want a powerful database engine that also has a small footprint while also offering an embedded edition that is completely aligned with its server counterparts. No other database vendor has successfully accomplished this achievement that I am aware of.
From your community member, Mark Rotteveel, he suggested that the reason for this lack of
Records Affected information from stored procedures with actionable DML was the idea that stored procedures act as isolated components (ie: decoupling). However, from my experience, this is taking the concept of decoupling a little too far. in the 2000s this concept was taken to such an extent that anything a developer created should be done via a generic design, which is an impossibility since generic design can only be efficiently implemented on static constructs such as for example, a date validation api. This prominent support for generic design was eventually forced back into reality when it was found that just the time alone to create all such development along this concept was unjustified.
Records Affected information from stored procedures with actionable DML was the idea that stored procedures act as isolated components (ie: decoupling). However, from my experience, this is taking the concept of decoupling a little too far. in the 2000s this concept was taken to such an extent that anything a developer created should be done via a generic design, which is an impossibility since generic design can only be efficiently implemented on static constructs such as for example, a date validation api. This prominent support for generic design was eventually forced back into reality when it was found that just the time alone to create all such development along this concept was unjustified.
In any event, whatever I have written about Firebird has always been very positive since I was immediately impressed with my first experiences with Interbase many years ago when I tinkered with it on my own. And I have been tracking the progress of Firebird for many years. However, my experiences with it discouraged me from using it until I decided that for the work I am doing now it was the best engine available.
And happily, I was correct...
Thank you again for your recent response to this query...
Steve Naidamast