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.
 

 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
 http://www.blackfalconsoftware.com http://www.blackfalconsoftware.com
 
 
 

 

 

 
 
  • [firebird-support]... blackfalconsoftw...@outlook.com [firebird-support]
    • Re: [firebird... Helen Borrie hele...@iinet.net.au [firebird-support]
      • Re: [fire... blackfalconsoftw...@outlook.com [firebird-support]
        • Re: [... 'livius' liviusliv...@poczta.onet.pl [firebird-support]

Reply via email to