Mijn persoonlijke voorkeur is om de bindvariabelen tekenreeksen (VARCHAR2) te maken en Oracle de conversie van teken naar zijn eigen interne opslagformaat te laten doen. Het is eenvoudig genoeg (in C) om gegevenswaarden weer te geven als null-beëindigde tekenreeksen, in een acceptabel formaat.
Dus, in plaats van SQL als volgt te schrijven:
SET MY_NUMBER_COL = :b1
, MY_DATE_COL = :b2
Ik schrijf de SQL als volgt:
SET MY_NUMBER_COL = TO_NUMBER( :b1 )
, MY_DATE_COL = TO_DATE( :b2 , 'YYYY-MM-DD HH24:MI:SS')
en geef tekenreeksen op als bindvariabelen.
Deze aanpak heeft een aantal voordelen.
Een daarvan is het omzeilen van de problemen en bugs die je tegenkomt bij het binden van andere gegevenstypen.
Een ander voordeel is dat bindwaarden gemakkelijker te ontcijferen zijn op een Oracle-gebeurtenis 10046-tracering.
Ook verwacht een EXPLAIN PLAN (denk ik) dat alle bindvariabelen VARCHAR2 zijn, dus dat betekent dat de verklaring die wordt uitgelegd iets anders is dan de daadwerkelijke instructie die wordt uitgevoerd (vanwege de impliciete gegevensconversies wanneer de datatypes van de bindargumenten in de werkelijke verklaring zijn niet VARCHAR2.)
En (minder belangrijk) wanneer ik de instructie in TOAD test, is het gemakkelijker om gewoon strings in de invoervakken te kunnen typen en niet te hoeven rommelen met het wijzigen van het gegevenstype in een vervolgkeuzelijst.
Ik laat ook de ingebouwde TO_NUMBER- en TO_DATE-functies de gegevens valideren. (In eerdere versies van Oracle heb ik problemen ondervonden met het rechtstreeks binden van een DATE-waarde, en het omzeilde (ten minste een deel van) de geldigheidscontrole en stond toe dat ongeldige datumwaarden in de database werden opgeslagen.
Dit is slechts een persoonlijke voorkeur, gebaseerd op ervaringen uit het verleden. Ik gebruik dezelfde aanpak met Perl DBD.
Ik vraag me af wat Tom Kyte (asktom.oracle.com) te zeggen heeft over dit onderwerp?