Devart Forums

Plash wrote:We will investigate possibility to add such option, but that is hardly to happen in the nearest future.

Thank you

I know it won't happen soon, but i was thinking about 'how to do it' ...

if you do it someday, don't test if parameter value is null.

Internally set a flag called 'value_set_by_user'. When a parameter is assigned you probably have a method setvalue, there you could toggle 'value_set_by_user' to true. That way users could set parameters to null if they want. When the query executes, check if all 'value_set_by_user' from all parameters = True.
After the query, reset the 'value_set_by_user' to False for all the parameters of the query.

Perhaps you'll have a better idea... but i wanted to share mine

Best regards

Plash wrote:These statements are executed if you use the TOraTrace component in your application. You should find this component in your application and delete it, or set the Enabled property of the component to False.

Thank you, you where right, someone dropped a TOratrace component on a form.

After removing TOratrace everything is working well again.

Thank you very much.

Hello,

DBmonitor shows that ODAC 6.10 launches the following alter session command after connecting to the database.

ALTER SESSION SET statistics_level = TYPICAL

ALTER SESSION SET timed_statistics = TRUE ;

ALTER SESSION SET EVENTS '10046 trace name context forever, level 1' ;

Can you explain why ? (we don't use statistics our queries are rule based)
perhaps an option can disable this ? The trace command is for debugging purpose ?

the first ALTER SESSION SET statistics_level = TYPICAL fails on oracle release 900010101 with the message ORA-02248.

Connecting to the database is still possible, but the error message raises.

jfudickar wrote:

Code: Select all

select count(*) from psysequence where NVL(psqjourmanuel, -1) = NVL(:PARAM, -1); 

This would be a valid way.

But i would agree with you, it could be an helpfull OPTIONAL property.

Greetings
Jens[/code]

Thank you Jens. well done

i was near to find it myself, but you were faster !

Plash wrote:We are not planning to add such option because in most cases it is correct when a programer sets a parameter value to NULL.

not sure .... because if i do those queries

SQL> select count(*) from psysequence where psqjourmanuel = null;

COUNT(*)
----------
0

SQL> select count(*) from psysequence where psqjourmanuel is null;

COUNT(*)
----------
132

i must use the IS operator, with the = opérator assigned here in my sample to a constant (but it woul also have the same effect with a parameter) the query executes but the result is wrong.

look like you cannot query a null value with parameters.


try the following

select * from psysequence where psqjourmanuel = :param1

will execute but return no rows (wrong result)

select * from psysequence where psqjourmanuel is :param1

will return an error requesting null keywork, cannot use parameters with IS

select * from psysequence where psqjourmanuel is null

will work but will not be parametric


I'm not tying to convince you, the feature is not absolutely necessary, i can live without . But i'm just wondering if null values can really be used in a query parameters ... maybe i'm wrong and you'll tell me

Do you know a case where setting NULL in a query parameter returns the rows where the column is null ? I'm myself not sure that's why i suggested the feature to be optionnal.

well, nevermind, thank you for reading me

hello,

It's just an idea, perhaps you could find it interresting.

I discovered that in a big query with many parameters, if i forget to set a parameter odac and oracle do not complain. The query just executes succesfully returning no rows.

I wonder if you could add an option (or if it exists already perhaps) called "EmptyparamValueWarning" in the session or the query component that would open a window with a warning when the query executes.

This parameter could be set to false by default for compatibility.

awaiting comments.

Cheers

Challenger wrote:You can find the "Create SQL" button right after "Overload" splitter in the top right corner of the window.

Oh yes thanks ! found it. I was searching in the parameters panel for a button with 'create sql' written on it. because when you click 'params' in the object inspector you get directly there.

Maybe the button shoud be visible in the parameters panel when the params list is empty ? not sure, just an idea.

Hello,

I'm now running ODAC 6.10.0.9

but i can't find the 'Create SQL' button in TOraStoredProc design-time editor.

ODAC revision history tells : Added 'Create SQL' button in TOraStoredProc design-time editor

Do you actually see the button ?

Good idea i agree

Thank you

Thank you.

Your solution is working well, the second port is closed now.

Just one question. Can you tell me wich feature or components require OCIEvents set to True ? Just in case we might want to use it someday.

Best regards

Hello,

Our firewall tells us our application compiled with ODAC 6 is opening a second listening port.

Compiled with the previous version ODAC 5.80 our application is only opening one port.

We use no oraalerter component, only Toraquery and Torastoredproc.

What is the second listening port usefull for ? Is this by design ? can ODAC 6 still work with one port ?

Thanks

Hello,

We set up a machine to test our application with ODAC 6.

we use many stored procs.

With ODAC 5 removing the StoredProcName value cleared the parameters.
Putting back the StoredProcName value forced ODAC to read again the parameters when clicking on Params.

This is broken in ODAC 6 and is not working anymore. The only way to get the parameters is to clic "execute" in the Params window. but then the OUT fields are no more null and the output values are stored in the DFM.

Thank you for investigating this issue

woaw you react really fast !

That's great ! Thank you very much.

In the meantime we switched back to odac 5.70, we'll check the new v6 release when available. I'll let you know if it works.

have a nice day

Thank you

Hello

I've found a minor issue with the TConnectDialog component

with ODAC 5 when Storeloginfo=TRUE and readaliases=TRUE

when .net=false Nserver value was read from the registry
when .net=true server value was read from the registry

now odac 6 seem to read and display the same value all the time when i change from .NET to normal at runtime.

If you connect first to with .net=TRUE then reconnect with .net=FALSE
the aliaslist is not rebuilt (this was working before)

Like i said it's not really a problem, just two little annoyances who are not working like before/expected

best regards