Hoi !

Hmmm ... let me tell this a bit different: Something about standards and
_de-facto_ standards and writing portable applications.

There IS a ISO/ANSI Standard for SQL (SQL/92 is the most commonly implemented),
and if I as a developer of portable Software write Database Programs I
just implement Querys that conform to this standard. If I do that from the
first line of code on, I will have compliance with any DB that is SQL/92
compliant.

There are many more Databases out there which basically implement SQL/92
and do not conform to the _de_facto_standard_ by Informix, Oracle, DB/2, 
MySQL, PostgreSQL and MS SQL

Whenever you write a Program for a specific DB and extend it for the next
big DB ... there will always be a new DB that does not adhere to the
_de_facto_standard_ ... 

Thats, why there are ISO/ANSI standards ... 

The ISO/ANSI standard says: if you want to insert a default value, use
the keyword "DEFAULT" ... so this would work with ANY DB, not just with
SAPDB. The '' value works with some DB's the DEFAULT works with any ...
which is better programming ?

The same is true for the single quote. The SQL standard says, that when
given within a String, you have to double it. This should also work with
ANY DB, not just the major ones ...

So maybe porting your application to SQL92 may make a better application
of it ....

I once 8 Years ago wrote an big SQL Application (something about 200000 
Lines, many SQL Statements), and it works with _ALL_ SQL92 DB'ses since
then without a line of change ... (tested with more than 10 DB's, not only
the five biggest ones .. there are much better DB's out there than Oracle
or Informix).

There is a good book about the SQL92 standard out there: 
A guide to THE SQL STANDARD by Chris J. Date, Hugh Darwen ... in Print by 
Addison Wesley.


  Ralf


> [This followup was posted to gmane.comp.db.sapdb.general and a copy was sent to 
> the cited author.]
> 
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> > Hi :-)
> > 
> > Because many DBM'ses accept something that does not mean that it is
> > valid SQL. That is not standard behaviour. 
> 
> I disagree. If I can use something in Informix, Oracle, DB/2, MySQL, PostgreSQL 
> and MS SQL (yes, tried them all this morning), then it is "de-facto standard 
> behaviour". 
> 
> If I have to spend days changing '' to DEFAULT, ; to // and \' to '' just 
> because, that I will be very careful next time I suggest anything to be ported 
> to run on SAP DB. I may still write new code, but definitely not port 
> __anything__.
> 
> Besides, where is the error in assigning "0" or '0' to an integer, as opposed 
> to assigning 0 to an integer? There is no other way to interpret "0", than the 
> value of 0. So why make life more complicate then it is, especially in case of 
> '' - there is no other way to interpret this then as "no value - assign 
> default". 
> 
> And it is working exactly like this, as long as the column does not have a 
> default assigned. Then it's ok. But it's not OK when there is an default. I do 
> not see any logic in this. For me, this is a bug. You can say that accepting 
> '' is a bug in the first place, but I say it is not, since this is de-facto 
> standard behaviour in any other RDBMS I tried, representing 99% of the market.
> 
> Whatever we might argue, fact is that in the end result, THERE IS NO 
> DIFFERENCE. So why not make it compatible, and save thousands of hours of 
> completely non-productive work?
> 
> > If you do not want to set
> > a value, just don't give it: (I also don't give user, password, 
> > maxrows,siteurl,options, so they will be set to their default values)
> > 
> > INSERT INTO PNCVS_headlines 
> >     (pn_id,pn_sitename,pn_rssurl) VALUES 
> >     (2,'PostNuke','http://postnuke.com/backend.php')
> > 
> > You will see this is much shorter and it _will_ work with any SQL DB.
> 
> Ralph,
> 
> Of course, you are right, but no matter how much I agree with you, this is 
> still not a solution for millions of lines of existing code, that is aalready 
> written.
> 
> It is a difference between having a SAP DB as a database system only for new 
> applications, or as a database system that can run existing applications too.
> 
> In my opinion, if only first is of interest, than SAP DB is fine. If you want 
> number two too, then it is not fine.
> 
> At this point, it is highly unlikely my SAP DB port will be accepted in 
> PostNuke CVS. I will reject it myself, if I was to make the decision. 
> 
> How about this SQL (PHP):
> 
> $result = $dbconn->Execute("INSERT INTO ".$prefix."_headlines VALUES 
> (1,'PostNuke',NULL,NULL,'','','','','Who\'s 
> online' ,10,'',20011122090726,'','0000000000000');");
> 
> will translate into:
> 
> $result = $dbconn->Execute("INSERT INTO ".$prefix."_headlines VALUES 
> (1,'PostNuke',NULL,NULL,".$default_value(sapdb).",".$default_value(sapdb).",".
> $default_value(sapdb).",".$default_value(sapdb).",'Who".$db_single_quote
> (sapdb)."s online',10,'',".db_timestamp_format(20011122090726,sapdb).",'',".
> $db_timestamp_format('0000000000000',sapdb).")".$db_sql_delimiter(sapdb)."");
> 
> Nice, isn't it?
> 
> 1: No, can't insert '00000000000000' in timestamp with SAP DB - No day "zero". 
> Can with any other database. Must use $db_timestamp_format()
> 
> 2: No, cannot terminate SQL with ';' . Can with any other database. Must use 
> $db_sql_delimiter()
> 
> 3: Cannot escape single quote with backslash, as I would in any other database. 
> Must use $db_single_quote()
> 
> 4: Cannot insert '20011122090726' in timestamp - must manually format it first. 
> Must use db_timestamp_format(20011122090726,sapdb)
> 
> 5: Cannot insert '' in column that has default, must use $default_value()
> 
> Would you accept this mess, just so you can accommodate one RDBMS, without 
> getting any additional benefit from making your code completely ridiculous?
> 
> Conclusion:
> 
> To SAP junta: Please, would you consider making SAP DB behave a bit more 
> according to de-facto standards. It would make porting existing code to SAP DB 
> much easier, not to say feasible. That would in turn speed up adoption of SAP 
> DB significantly. Thank you.
> 
> Regards,
> 
> -- 
> Yours, Andrej Falout, http://www.falout.com/disclaimer.html
> Visit the OpenSource alternative, Aubit 4gl: http://aubit4gl.sourceforge.net
> PLEASE NOTE: All HTML email sent to me WILL BE DELETED AUTOMATICALLY WITHOUT 
> READING.
> 
> 
> _______________________________________________
> sapdb.general mailing list
> [EMAIL PROTECTED]
> http://listserv.sap.com/mailman/listinfo/sapdb.general
> 

-- 
theCo.de AG
Oranienstr. 10-11, 10997 Berlin
fon +49 30 617 897-0  fax -10
[EMAIL PROTECTED] http://www.theCo.de
_______________________________________________
sapdb.general mailing list
[EMAIL PROTECTED]
http://listserv.sap.com/mailman/listinfo/sapdb.general

Reply via email to