Feature Details
Ratings/ Comments
Implicit conversions result in wrong and different explain plans vs the same query in your plsql code using variables. So it's not reliable to use. 1028-MAY-20
would be usefull1028-FEB-20
Definitely needed.1023-OCT-19
Important feature. Allows running sqltext from v$sql without editing for bind variable support. Implicit conversions can also impact explain plan.1005-AUG-19
Very important1008-MAY-19
Much needed feature. Implicit conversions do not always work well for the optimizer and OUT variables in the like of REF_CURSORS are not possible.1008-MAY-19
Most wanted: Date(Time) input without TO_DATE conversion1017-JAN-19
awaiting community votes for 11 years...1020-DEC-18
Much needed1013-NOV-18
Most useful feature1027-JUN-18
Helps a lot while running the queries. 1015-NOV-17
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.1019-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.1014-DEC-15
Yes, this is very useful for DATE bind variable.1009-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.1013-APR-15
For date bind variables badly needed1003-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.1030-DEC-14
Would be cool, esp. if it would somehow allow to bind the result of some plsql function.1018-SEP-14
Would be useful.804-APR-14
Important if you should change from other tools1023-OCT-13
Implicit conversion might cause a different execution plan.1014-AUG-13
Implicit type conversions have unpredictable results.1024-JUL-13
It's a must. Specially when working with date variables1023-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.1012-MAR-13
Also, it should default to the column type (in the query for example)1022-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.1007-JUN-12
Should be nice.827-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. For example, 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.810-AUG-10
The implicit type conversion doesn't always work714-SEP-08
Much better than having to put to_date() or cast( as ) calls in the code to convert bind variable data types.615-FEB-07
1 - 61