Bind Variables in TDA 2.6.0.561

Hello all!!!

I’ve found that BIND VARIABLES function in TDA 2.6.0.561 is not working as in the previous version (TDA 2.5.1.952)

  1. In TDA 2.5.1, the BIND VARIABLES window always “remebered” the last values entered in the NAME, TYPE, DIRECTION, and VALUE fields. In TDA 2.6.0 the BIND VARIABLES always displays a “fresh” configuration, with the TYPE field defined as VARCHAR, and the VALUE field is EMPTY, so every time you have to enter the values again and again, also for running the very same query.

  2. In TDA 2.5.1, when using BIND VARIABLES with 2 variables (DATE_START and DATE_FINISH) of DATETIME type, it was possible to set different TIME for each one (i.e: DATE_START = ‘01/01/2010 00:00’ and DATE_FINISH = ‘01/01/2010 23:59’). Now, in TDA 2.6.0 I can’t even find the way to display/set the TIME when the CALENDAR shows up during setting the value for a DATETIME variable.

Sorry for my BAD english :slight_smile: I hope you guys can help me out on this, because I’m thinking in downgrading to TDA 2.5.1 again.

Thanks in advance!

Message was edited by: oscargh1_531

I tested your two examples on a Native Oracle connection and both the bind values are retained and the date picker when using Date bind type selects specified date.

What type of connection are you using? Please provide sample sql and/screen shot so I can produce what you are experiencing.

Debbie

How can I verify that I am using a Native Oracle connection, I am experiencing the same issue with my bind variables.

Thanks,

Jon

Right click on your connection in the conneciton manager and choose properties. See attached screenshot to determine if native connection. If you do not have a native connection, please define one and retry. If you have a native connection, please list more details on how to reproduce the issue.
Debbie

So, I am using an Native Oracle connection, and the bind variables are not being maintained across executions. If I browse to the Settings.xml file in “C:\Users{UserName}\AppData\Roaming\Quest Software\Toad for Data Analysts 2.6” I can see the bind variables are being stored, but they are not being populated in the Bind Variables dialog. This is happening on all of our installations of Toad for Data Analysts since we upgraded from the beta to the release version.

Attached are some screenshots of what happens.
Bind Variables Populated.png

So, I am using an Native Oracle connection, and the bind variables are not being maintained across executions. If I browse to the Settings.xml file in “C:\Users{UserName}\AppData\Roaming\Quest Software\Toad for Data Analysts 2.6” I can see the bind variables are being stored, but they are not being populated in the Bind Variables dialog. This is happening on all of our installations of Toad for Data Analysts since we upgraded from the beta to the release version.

Attached are some screenshots of what happens.
Subsequent Run.png

So, I am using an Native Oracle connection, and the bind variables are not being maintained across executions. If I browse to the Settings.xml file in “C:\Users{UserName}\AppData\Roaming\Quest Software\Toad for Data Analysts 2.6” I can see the bind variables are being stored, but they are not being populated in the Bind Variables dialog. This is happening on all of our installations of Toad for Data Analysts since we upgraded from the beta to the release version.

Attached are some screenshots of what happens.
First Run.png

WHERE (ORDERS.ORDER_DATE = TO_DATE(:a, ‘MM-DD-YYYY’))

Thanks for brining this to our attention.

Debbie

FROM QUEST_STAGE.ORDERS ORDERS

Mnnnnn…I didn’t try DATE bind variables. You are correct we are not retaining the values. I entered CR73,254 to fix. In the meantime a work around would be to use the to_date function with variable. Since this variable is a string it will remember the value.

IE: SELECT ORDERS.ORDER_DATE

Thanks for the prompt response. We will use the workaround for now, how soon should we expect a service release with the bugfix?

Regards,

Jon

Message was edited by: jonk_187

This issue will be included in our 2.7 release. We will also try to include in the earliest Beta once we start those.

Debbie

Hello all, again!!!!

Sorry for my late reply. I was out on a long-and-well-deserved vacation that kept me away from Internet. But, I'm back now :smiley:

Thank you all for paying attention on the issues I reported. It's glad to know that there's someone on the other side of the screen that works for making TDA the best tool for DB :smiley:

I would like to remark the second issue I reported on my original message: I attached 2 images.

First one is from an Oracle Native Connection using "DATE" BIND VARIABLES, where it is possible to pick a date AND a time.

Second one is the same scenario, but on a MySQL native connection using "DATETIME" BIND VARIABLES, but in this case it is possible to pick a date BUT NOT a time (the TIME PICKER is missing in the small window - In the Oracle connection it was present)

Am I doing anything wrong? Is there any other way to pick a DATE and a TIME using a "DATETIME" BIND VARIABLE in a MySQL Native conn? I've found a "workarond" that consist in first selecting "VARCHAR", then type in the DATE & TIME (example: 26/04/2010 11:59:59 p.m.), then switch to "DATETIME", and finally click OK! It works nice, but it is annoying to have to do this every time with every new variable.

Hope you guys can take a look at this as you kindly did with the other issue I reported.

Thanks in advance!!!!!!

Hello all!!!

I've found that BIND VARIABLES function in TDA
2.6.0.561 is not working as in the previous version
(TDA 2.5.1.952)

  1. In TDA 2.5.1, the BIND VARIABLES window always
    "remebered" the last values entered in the NAME,
    TYPE, DIRECTION, and VALUE fields. In TDA 2.6.0 the
    BIND VARIABLES always displays a "fresh"
    configuration, with the TYPE field defined as
    VARCHAR, and the VALUE field is EMPTY, so every time
    you have to enter the values again and again, also
    for running the very same query.

  2. In TDA 2.5.1, when using BIND VARIABLES with 2
    variables (DATE_START and DATE_FINISH) of DATETIME
    type, it was possible to set different TIME for each
    one (i.e: DATE_START = '01/01/2010 00:00' and
    DATE_FINISH = '01/01/2010 23:59'). Now, in TDA 2.6.0
    I can't even find the way to display/set the TIME
    when the CALENDAR shows up during setting the value
    for a DATETIME variable.

Sorry for my BAD english :slight_smile: I hope you guys can help
me out on this, because I'm thinking in downgrading
to TDA 2.5.1 again.

Thanks in advance!

Ooops!!!... I'm sorry I forgot to attach the images in my previous message.

Here they are...

Ooops!!!... I'm sorry I forgot to attach the images in my previous message.

Here they are...

The datetime picker with the abiltiy to enter the time portion is a new addition to TDA 2.6. It looks like it was only impelemented with binds for Oracle and non of the other providers got it. I entered CR73,856 to add this. Looks like your work around will have to do for now. Sorry. But thanks for pointing this out.

Debbie

Thanks for your kind, helpful and fast response, Debbie.

I’m glad you take in consideration comments from users like me. The idea is to improve TDA and make it versatile and useful for everyone.

Thanks again! I’ll wait anxiously for the upcoming fixes and features :smiley:

My pleasure:)

Hello All,

I’m checking this all over again using TDA v2.7, and the problem is still present. DATE BIND VARIABLES values are not being retained in v2.7 (it works OK in TDA 2.5).

I’m using MySQL 5.1 native connection and I have to re-enter BIND VARIABLES values every time I run a query. I’ll point this out because in previous comments were stated that this issue will be solved in v2.7.

Hope you guys can take a look at this!!

Best regards,
Oscar

UPDATE!

Also, the DATETIME picker isn’t working OK, because the HOUR selection box is missing using MySQL 5.1 native connection.

This post was in regards to Oracle connections and binds. We seemed to have only focused on making this work in Oracle and did not check MySQL. I have entered CR80,190 for MySQL. Please confirm that it works for you on Oracle.

Debbie

Yes. This is related to the bind issues and will be fixed by the same CR (80,190)