|Addressing the development comment, if implicit conversions aren't the best method for addressing data access (and they aren't) then you shouldn't be using this as your default. Effort has already gone into the bind interface to specify that someone can enforce a value of null, instead of just leaving the value window empty. It isn't a great leap to offer an option to force the value in the window to be cast as a date.||10||19-OCT-16|
|It's very much needed. It's a pain to change 20 params to (to_date) in the code back and forth when developing and putting the code to the production.||10||14-DEC-15|
|Yes, this is very useful for DATE bind variable.||10||09-OCT-15|
|This is much needed functionality. I'm currently unable to test a block of code that uses bind variables that need to be DATE types.||10||13-APR-15|
|For date bind variables badly needed||10||03-MAR-15|
|As Thomas Kyte said: Implicit conversions are logic bombs!
We had lots of problems due to implicit conversions causing full table scans in our production environment.||10||30-DEC-14|
|Would be cool, esp. if it would somehow allow to bind the result of some plsql function.||10||18-SEP-14|
|Would be useful.||8||04-APR-14|
|Important if you should change from other tools||10||23-OCT-13|
|Implicit conversion might cause a different execution plan.||10||14-AUG-13|
|Implicit type conversions have unpredictable results.||10||24-JUL-13|
|It's a must. Specially when working with date variables||10||23-MAY-13|
|The implicit conversions fail quite often with dates and the UI should have a better interface when entering a type like a date, letting you use a calendar and entering a time.||10||12-MAR-13|
|Also, it should default to the column type (in the query for example)||10||22-JAN-13|
|Badly needed. When I am debugging a complex query extracted from an Oracle Report and this query has dates, then implicit conversions do not always work. For example, if my query calls an overloaded function, for which the difference between 2 versions of the function is that one of my parameters is a date in version 1 and a string in version 2, then I cannot specify in SQLDev as to what is the type of my Bind Variable. Toad makes a first guess at the type, but allows you to override this. Oracle Reports allows you to specify the data type, so that the bind variables in the SQL query "know" the type.||10||07-JUN-12|
|Should be nice.||8||27-JUN-11|
|I know I can convert using the TO_DATE(), but this can be a pain for large, complex queries.
I find the lack of this feature especially frustrating when working with BI Publisher queries BIP parameters are typed, so I have to add/remove bind variable date handling when working on a BIP query in SQL Developer.
AND CAST(date_utils.CONVERT_TIME_ZONE(sc.schedule_date, 'UTC', :Store_Timezone) AS DATE) BETWEEN TRUNC(to_date(:from_date, 'DD MON YY')) AND (TRUNC(to_date(:to_date, 'DD MON YY')) + .99999)
Being able to type bind variables would save a lot of time and effort for me.||8||10-AUG-10|
|The implicit type conversion doesn't always work||7||14-SEP-08|
|Much better than having to put to_date() or cast( as ) calls in the code to convert bind variable data types.||6||15-FEB-07|