Thread: [cx-oracle-users] an old question
Brought to you by:
atuining
Menu
▾
▴
cx-oracle-users
|
From: Glyph <gl...@tw...> - 2013-04-18 21:51:38
|
Hello fellow cx_Oracle'ers: I asked what I thought was a very simple question on Stack Overflow about a year and a half ago, but it still doesn't have an answer. In short: how do I get any results out of inline PL/SQL? <http://stackoverflow.com/questions/7843551/how-do-i-retrieve-data-from-oracle-as-a-query-result-using-an-anonymous-pl-sql-b> If anyone would like to answer the question, either here or there, I'd still appreciate it. -glyph |
|
From: Mark H. <mh...@pi...> - 2013-04-18 22:12:15
|
On 4/18/13 2:51 PM, Glyph wrote: > Hello fellow cx_Oracle'ers: > > I asked what I thought was a very simple question on Stack Overflow about a year and a half ago, but it still doesn't have an answer. > > In short: how do I get any results out of inline PL/SQL? > > <http://stackoverflow.com/questions/7843551/how-do-i-retrieve-data-from-oracle-as-a-query-result-using-an-anonymous-pl-sql-b> > > If anyone would like to answer the question, either here or there, I'd still appreciate it. I've typed in an answer... let me know if it is useful! |
|
From: Glyph <gl...@tw...> - 2013-04-18 22:48:41
|
On Apr 18, 2013, at 3:12 PM, Mark Harrison <mh...@pi...> wrote: > On 4/18/13 2:51 PM, Glyph wrote: >> Hello fellow cx_Oracle'ers: >> >> I asked what I thought was a very simple question on Stack Overflow about a year and a half ago, but it still doesn't have an answer. >> >> In short: how do I get any results out of inline PL/SQL? >> >> <http://stackoverflow.com/questions/7843551/how-do-i-retrieve-data-from-oracle-as-a-query-result-using-an-anonymous-pl-sql-b> >> >> If anyone would like to answer the question, either here or there, I'd still appreciate it. > > I've typed in an answer... let me know if it is useful! Thanks for responding, but, unfortunately, no. I put a comment there, but in short; I know that it's unusual, but there are cases where inline PL/SQL can do things that regular SQL can't. Is there any way to emit data back to the application from an inline block like this? -glyph |
|
From: Christopher J. <chr...@or...> - 2013-04-18 23:03:15
|
On 04/18/2013 03:48 PM, Glyph wrote: > > On Apr 18, 2013, at 3:12 PM, Mark Harrison <mh...@pi... <mailto:mh...@pi...>> wrote: > >> On 4/18/13 2:51 PM, Glyph wrote: >>> Hello fellow cx_Oracle'ers: >>> >>> I asked what I thought was a very simple question on Stack Overflow about a year and a half ago, but it still doesn't have an answer. >>> >>> In short: how do I get any results out of inline PL/SQL? >>> >>> <http://stackoverflow.com/questions/7843551/how-do-i-retrieve-data-from-oracle-as-a-query-result-using-an-anonymous-pl-sql-b> >>> >>> If anyone would like to answer the question, either here or there, I'd still appreciate it. >> >> I've typed in an answer... let me know if it is useful! > > Thanks for responding, but, unfortunately, no. I put a comment there, but in short; I know that it's unusual, but there are cases where inline PL/SQL can do things that regular SQL can't. > > /Is/ there any way to emit data back to the application from an inline block like this? > Does PL/SQL's PIPE ROW functionality fit your use case? See http://docs.oracle.com/cd/E11882_01/appdev.112/e25519/tuning.htm#BABDGCDH Chris -- chr...@or... http://twitter.com/ghrd Newly updated, free PHP & Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html |
|
From: Paul M. <p.f...@gm...> - 2013-04-19 08:04:31
|
On 18 April 2013 23:48, Glyph <gl...@tw...> wrote: > Thanks for responding, but, unfortunately, no. I put a comment there, but > in short; I know that it's unusual, but there are cases where inline PL/SQL > can do things that regular SQL can't. > > *Is* there any way to emit data back to the application from an inline > block like this? > Can you give an example of your actual code? In general, the answer to your question is "no", because PL/SQL blocks are not select statements and therefore do not return rows via the cursor. But there are ways, depending on the details of what you want to do. Your requirement to not modify the schema (specifically not creating stored procedures) makes it hard, though... Paul |
|
From: Glyph <gl...@tw...> - 2013-04-28 00:24:47
|
On Apr 19, 2013, at 1:04 AM, Paul Moore <p.f...@gm...> wrote:
> On 18 April 2013 23:48, Glyph <gl...@tw...> wrote:
> Thanks for responding, but, unfortunately, no. I put a comment there, but in short; I know that it's unusual, but there are cases where inline PL/SQL can do things that regular SQL can't.
>
> Is there any way to emit data back to the application from an inline block like this?
>
> Can you give an example of your actual code? In general, the answer to your question is "no", because PL/SQL blocks are not select statements and therefore do not return rows via the cursor. But there are ways, depending on the details of what you want to do. Your requirement to not modify the schema (specifically not creating stored procedures) makes it hard, though...
I want to do something like this:
cursor.execute("""
begin
-- mumble declare 'something' somehow
delete from foo where bar = 1 returning baz into :something;
-- send rows from :something into the output that will come from .fetchall();
end;
""")
cursor.fetchall()
because the desire to atomically get rows out of a 'delete' statement is not a table-specific stored procedure. I also don't want to create any temporary tables, because again, this is not in any way specific to one table; I just want to know what it is that I deleted or updated when I look at the results of a delete or update statement.
Currently, I'm doing this with host variables, but that's a limited solution because I have to know ahead of time whether I expect a single row, or multiple rows, and if I expect multiple rows, array variables can hold a maximum of 4000 elements (or is it 4000 bytes? documentation seems unclear).
Anyway, generating these as "regular" database output seems like a much saner and more scalable option, so I'd love to know how to do it.
Thanks for your time!
-glyph
|
|
From: Paul M. <p.f...@gm...> - 2013-04-29 20:00:59
|
OK, got you. (BTW, sorry for the delay in responding, your mail only just
arrived on the list).
I don't think this is possible. DELETE RETURNING is a PL/SQL construct
which gives you the deleted rows back as a collection. You *might* be able
to put those into a refcursor somehow, but frankly I can't think of a way
that doesn't need you to create a stored procedure/function in the
database. If you can do that, a pipelined function would probably give you
what you need. (Someone else posted an example elsewhere in the thread that
you could probably get to work).
Sorry I can't be of more help...
Paul
On 19 April 2013 17:56, Glyph <gl...@tw...> wrote:
>
> On Apr 19, 2013, at 1:04 AM, Paul Moore <p.f...@gm...> wrote:
>
> On 18 April 2013 23:48, Glyph <gl...@tw...> wrote:
>
>> Thanks for responding, but, unfortunately, no. I put a comment there,
>> but in short; I know that it's unusual, but there are cases where inline
>> PL/SQL can do things that regular SQL can't.
>>
>> *Is* there any way to emit data back to the application from an inline
>> block like this?
>>
>
> Can you give an example of your actual code? In general, the answer to
> your question is "no", because PL/SQL blocks are not select statements and
> therefore do not return rows via the cursor. But there are ways, depending
> on the details of what you want to do. Your requirement to not modify the
> schema (specifically not creating stored procedures) makes it hard,
> though...
>
>
> I want to do something like this:
>
> cursor.execute("""
> begin
> -- mumble declare 'something' somehow
> delete from foo where bar = 1 returning baz into :something;
> -- send rows from :something into the output that will come from
> .fetchall();
> end;
> """)
> cursor.fetchall()
>
>
> because the desire to atomically get rows out of a 'delete' statement is
> not a table-specific stored procedure. I also don't want to create any
> temporary tables, because again, this is not in any way specific to one
> table; I just want to know what it is that I deleted or updated when I look
> at the results of a delete or update statement.
>
> Currently, I'm doing this with host variables, but that's a limited
> solution because I have to know ahead of time whether I expect a single
> row, or multiple rows, and if I expect multiple rows, array variables can
> hold a maximum of 4000 elements (or is it 4000 bytes? documentation seems
> unclear).
>
> Anyway, generating these as "regular" database output seems like a much
> saner and more scalable option, so I'd love to know how to do it.
>
> Thanks for your time!
>
> -glyph
>
>
>
> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
> _______________________________________________
> cx-oracle-users mailing list
> cx-...@li...
> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>
>
|
|
From: Glyph <gl...@tw...> - 2013-04-30 07:24:34
|
On Apr 29, 2013, at 1:00 PM, Paul Moore <p.f...@gm...> wrote: > OK, got you. (BTW, sorry for the delay in responding, your mail only just arrived on the list). Yeah, a couple of outgoing mails got stuck. Sorry! > I don't think this is possible. DELETE RETURNING is a PL/SQL construct which gives you the deleted rows back as a collection. You *might* be able to put those into a refcursor somehow, but frankly I can't think of a way that doesn't need you to create a stored procedure/function in the database. If you can do that, a pipelined function would probably give you what you need. (Someone else posted an example elsewhere in the thread that you could probably get to work). Backing off from "delete returning" for a moment; what is the implicit "output" cursor called from an inline PL/SQL statement? If I knew that, I could at least try stuffing some rows into it. Is it just inaccessible from PL/SQL? -glyph |
|
From: Anthony T. <ant...@gm...> - 2013-04-29 20:25:35
|
It is possible -- at least so long as I understand what you are trying to
do. Here is an example:
NUM_ENTRIES = 25 # maximum number of entries that can be expected
connection = cx_Oracle.Connection("user/pw@tns")
cursor = connection.cursor()
returningVar = cursor.arrayvar(int, NUM_ENTRIES)
cursor.execute("""
begin
delete from TestExecuteMany
where rownum <= 5
returning IntCol bulk collect into :output;
end;""",
output = returningVar)
for intCol in returningVar.getvalue():
print "DELETED", intCol
Hope that helps.
Anthony
On Mon, Apr 29, 2013 at 2:00 PM, Paul Moore <p.f...@gm...> wrote:
> OK, got you. (BTW, sorry for the delay in responding, your mail only just
> arrived on the list).
>
> I don't think this is possible. DELETE RETURNING is a PL/SQL construct
> which gives you the deleted rows back as a collection. You *might* be able
> to put those into a refcursor somehow, but frankly I can't think of a way
> that doesn't need you to create a stored procedure/function in the
> database. If you can do that, a pipelined function would probably give you
> what you need. (Someone else posted an example elsewhere in the thread that
> you could probably get to work).
>
> Sorry I can't be of more help...
> Paul
>
>
> On 19 April 2013 17:56, Glyph <gl...@tw...> wrote:
>
>>
>> On Apr 19, 2013, at 1:04 AM, Paul Moore <p.f...@gm...> wrote:
>>
>> On 18 April 2013 23:48, Glyph <gl...@tw...> wrote:
>>
>>> Thanks for responding, but, unfortunately, no. I put a comment there,
>>> but in short; I know that it's unusual, but there are cases where inline
>>> PL/SQL can do things that regular SQL can't.
>>>
>>> *Is* there any way to emit data back to the application from an inline
>>> block like this?
>>>
>>
>> Can you give an example of your actual code? In general, the answer to
>> your question is "no", because PL/SQL blocks are not select statements and
>> therefore do not return rows via the cursor. But there are ways, depending
>> on the details of what you want to do. Your requirement to not modify the
>> schema (specifically not creating stored procedures) makes it hard,
>> though...
>>
>>
>> I want to do something like this:
>>
>> cursor.execute("""
>> begin
>> -- mumble declare 'something' somehow
>> delete from foo where bar = 1 returning baz into :something;
>> -- send rows from :something into the output that will come from
>> .fetchall();
>> end;
>> """)
>> cursor.fetchall()
>>
>>
>> because the desire to atomically get rows out of a 'delete' statement is
>> not a table-specific stored procedure. I also don't want to create any
>> temporary tables, because again, this is not in any way specific to one
>> table; I just want to know what it is that I deleted or updated when I look
>> at the results of a delete or update statement.
>>
>> Currently, I'm doing this with host variables, but that's a limited
>> solution because I have to know ahead of time whether I expect a single
>> row, or multiple rows, and if I expect multiple rows, array variables can
>> hold a maximum of 4000 elements (or is it 4000 bytes? documentation seems
>> unclear).
>>
>> Anyway, generating these as "regular" database output seems like a much
>> saner and more scalable option, so I'd love to know how to do it.
>>
>> Thanks for your time!
>>
>> -glyph
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Try New Relic Now & We'll Send You this Cool Shirt
>> New Relic is the only SaaS-based application performance monitoring
>> service
>> that delivers powerful full stack analytics. Optimize and monitor your
>> browser, app, & servers with just a few lines of code. Try New Relic
>> and get this awesome Nerd Life shirt!
>> http://p.sf.net/sfu/newrelic_d2d_apr
>>
>> _______________________________________________
>> cx-oracle-users mailing list
>> cx-...@li...
>> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>>
>>
>
>
> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
> _______________________________________________
> cx-oracle-users mailing list
> cx-...@li...
> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>
>
|
|
From: Glyph <gl...@tw...> - 2013-04-30 07:21:55
|
On Apr 29, 2013, at 1:25 PM, Anthony Tuininga <ant...@gm...> wrote: > It is possible -- at least so long as I understand what you are trying to do. Here is an example: As I keep pointing out: >> Currently, I'm doing this with host variables, but that's a limited solution [...] I'm aware of the cursor.var() solution; I'm looking for one which doesn't involve one of those, since that means (A) custom Python code for Oracle, where other databases (PostgreSQL, MySQL, SQLite) just require custom SQL generation, and (B) foreknowledge of the maximum number of results that will come back from one of these statements. -glyph |
|
From: Mark H. <mh...@pi...> - 2013-04-30 08:04:52
|
On 4/30/13 12:21 AM, Glyph wrote: > As I keep pointing out: > >>> Currently, I'm doing this with host variables, but that's a limited solution [...] You're trying but apparent failing to make your point... I tried helping you out earlier, but your response left me not caring a lot whether or not you solved your problem or not. |
|
From: Glyph <gl...@tw...> - 2013-04-30 08:17:31
|
On Apr 30, 2013, at 1:04 AM, Mark Harrison <mh...@pi...> wrote: > On 4/30/13 12:21 AM, Glyph wrote: >> As I keep pointing out: >> >>>> Currently, I'm doing this with host variables, but that's a limited solution [...] > > You're trying but apparent failing to make your point... > > I tried helping you out earlier, but your response left me not > caring a lot whether or not you solved your problem or not. I do appreciate you taking the time to help, even if your answer wasn't directly useful to me. I realize what I'm looking for is a bit esoteric. "What you are trying to do is impossible" is a totally acceptable answer - I am really just trying to understand why Oracle makes this impossible. The database-specificity of cursor.var() makes sense to me, idiomatically, but the restricted size of query results seems odd. For example, if I want to 'delete...returning...into...' a million rows, rather than the default allowed ~1000 or so, how can I do that? Would a pipelined procedure with PIPE ROW address this problem, and the general expectation is just that I'd be able to put such a procedure into my schema? -glyph |
|
From: Paul M. <p.f...@gm...> - 2013-04-30 08:40:36
|
On 30 April 2013 09:17, Glyph <gl...@tw...> wrote:
> I do appreciate you taking the time to help, even if your answer wasn't
> directly useful to me. I realize what I'm looking for is a bit esoteric.
> "What you are trying to do is impossible" is a totally acceptable answer -
> I am really just trying to understand *why* Oracle makes this impossible.
>
I think the big issue here is that people with an Oracle background (like
me) just don't understand the question, because fundamentally the
principles are different. (I say this because I've had endless frustrating
conversations with a friend who's an Ingres specialist, and we always end
up realising that neither of us *actually* understands the fundamental
terms that the other person is using, even though we thought we did...)
This may be basic stuff you already know, but for purposes of clarity,
Oracle runs statements in 3 steps - parse, execute and fetch. Only select
statements need a fetch phase, all other statements run in the execute
phase. Think of it as "only select statements produce a cursor you can
fetch from" if you like.
The basic problem here is that PL/SQL is not a select, so it completes in
the execute phase. With PL/SQL you can *create* cursors, and pass them
round, but they are not "the result of the execute phase" and so won't ever
be accessible directly from the cx_Oracle cursor object. That's why you
need a variable of some sort.
One exception is that you can *wrap* your PL/SQL in a select. But to do
that you need a defined function in the schema - that's where the
suggestion of a pipelined function comes from. With that you'd do
cursor.execute("select * from
table(function_doing_your_work_and_piping_rows())") and then read the
cursor. But yes, that requires a function defined in the schema. And it's
going to return a specific set of columns (so you need one per table, in
effect). The reason for the latter restriction is that Oracle expects
cursors to be statically defined (SYS_REFCURSOR is an exception, but that's
getting a bit deep for now).
Someone said that you may be able to have an "inline" function definition
in your SQL in the not yet released 12c. That might help you, but I presume
you'd want a solution that worked for a currently released version :-)
> The database-specificity of cursor.var() makes sense to me, idiomatically,
> but the restricted size of query results seems odd. For example, if I want
> to 'delete...returning...into...' a million rows, rather than the default
> allowed ~1000 or so, how can I do that? Would a pipelined procedure with
> PIPE ROW address this problem, and the general expectation is just that I'd
> be able to put such a procedure into my schema?
>
I believe that how that works is that you're returning the data into a
PL/SQL array, then converting that into a cursor. So there's a materialised
array of values in there, and allowing for a million entries will have a
memory cost. You could declare an array that big, if the memory wasn't an
issue to you, but again it's about static objects, you have to declare
*some* limit up front.
Yes a procedure with PIPE ROW would address this - that's the key point
about PIPE ROW is taht it sends the rows "on demand" rather than
materialising the whole array.
Paul
|
|
From: Glyph <gl...@tw...> - 2013-04-30 19:45:24
|
Hi Paul, On Apr 30, 2013, at 1:40 AM, Paul Moore <p.f...@gm...> wrote: > This may be basic stuff you already know, but for purposes of clarity, Oracle runs statements in 3 steps - parse, execute and fetch. Only select statements need a fetch phase, all other statements run in the execute phase. Think of it as "only select statements produce a cursor you can fetch from" if you like. Everything else you said in your message was interesting, and I learned a lot from all of it, but this paragraph really nailed my problem. In fact, I did not know about these 3 steps, and I didn't realize that the cursor was (effectively) synthesized as a result of the execution of the 'select'. In other database I've dealt with, query execution works somewhat differently, and I was bringing that expectation to Oracle. Thanks a ton! -glyph |
|
From: Chris G. <chr...@to...> - 2013-04-30 08:50:55
|
Hi - I've been following the discussion in this thread and have to say I think the objective of the whole exercise is flawed. You seem to be trying to write a set of wrappers to make Oracle appear to behave in the same way as other RDBMS, and I think that isn't realistic. To get the best out of any database you need to exploit its features and avoid its "quirks". Oracle's features include returning a data-sets as a REFCURSOR where you don't know in advance how many records are in the set - you and Oracle only find that out when you fetch past the last row. Similarly, if you're talking of deleting a million rows and trying to return all the deleted data into a collection of some sort that gets passed back to the invoker, what are you going to do with that data? It sounds like you'd be better off trying a "SELECT .. FOR UPDATE" and then deleting each row - inefficient in Oracle, but that seems to be of secondary importance. I really think the further you go with this, the more problems you're likely to encounter and you're never going to get any decent performance out of what is a very expensive RDBMS. C On 30 April 2013 09:17, Glyph <gl...@tw...> wrote: > > On Apr 30, 2013, at 1:04 AM, Mark Harrison <mh...@pi...> wrote: > > On 4/30/13 12:21 AM, Glyph wrote: > > As I keep pointing out: > > Currently, I'm doing this with host variables, but that's a limited > solution [...] > > > You're trying but apparent failing to make your point... > > I tried helping you out earlier, but your response left me not > caring a lot whether or not you solved your problem or not. > > > I do appreciate you taking the time to help, even if your answer wasn't > directly useful to me. I realize what I'm looking for is a bit esoteric. > "What you are trying to do is impossible" is a totally acceptable answer - > I am really just trying to understand *why* Oracle makes this impossible. > > The database-specificity of cursor.var() makes sense to me, idiomatically, > but the restricted size of query results seems odd. For example, if I want > to 'delete...returning...into...' a million rows, rather than the default > allowed ~1000 or so, how can I do that? Would a pipelined procedure with > PIPE ROW address this problem, and the general expectation is just that I'd > be able to put such a procedure into my schema? > > -glyph > > > > ------------------------------------------------------------------------------ > Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET > Get 100% visibility into your production application - at no cost. > Code-level diagnostics for performance bottlenecks with <2% overhead > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap1 > _______________________________________________ > cx-oracle-users mailing list > cx-...@li... > https://lists.sourceforge.net/lists/listinfo/cx-oracle-users > > |
|
From: Meyer M. <Mat...@ge...> - 2013-04-30 09:28:11
|
Hi, I think Chris is correct. I also like his approach with SELECT.. FOR UPDATE If I read correctly, I think, what the OP is trying to do is some kind of historization. But there are already a number of patterns for that. If I remember correctly there are 3 ways: - You add a %_old column for each column you want historized. So you have for each column exactly one historic data item. - You add a version_id column. This gives you complete history, but makes queries harder and asks for a clever index. Also you could add a few views, which gives you all the "current" records. Some people also add a is_current column, to ease filtering. - You add a history-table into which you move all old records. For all 3 patterns, you add audit-columns in which you record when and why you changed the record. But maybe the OP can tell us more about what he is actually trying to do. Kind regards and thanks for all the interesting stuff I learned, reading this thread.. Matthias ________________________________________ Von: Chris Gould [mailto:chr...@to...] Gesendet: Dienstag, 30. April 2013 10:50 An: cx-...@li... Betreff: Re: [cx-oracle-users] an old question Hi - I've been following the discussion in this thread and have to say I think the objective of the whole exercise is flawed. You seem to be trying to write a set of wrappers to make Oracle appear to behave in the same way as other RDBMS, and I think that isn't realistic. To get the best out of any database you need to exploit its features and avoid its "quirks". Oracle's features include returning a data-sets as a REFCURSOR where you don't know in advance how many records are in the set - you and Oracle only find that out when you fetch past the last row. Similarly, if you're talking of deleting a million rows and trying to return all the deleted data into a collection of some sort that gets passed back to the invoker, what are you going to do with that data? It sounds like you'd be better off trying a "SELECT .. FOR UPDATE" and then deleting each row - inefficient in Oracle, but that seems to be of secondary importance. I really think the further you go with this, the more problems you're likely to encounter and you're never going to get any decent performance out of what is a very expensive RDBMS. C On 30 April 2013 09:17, Glyph <gl...@tw...> wrote: On Apr 30, 2013, at 1:04 AM, Mark Harrison <mh...@pi...> wrote: On 4/30/13 12:21 AM, Glyph wrote: As I keep pointing out: Currently, I'm doing this with host variables, but that's a limited solution [...] You're trying but apparent failing to make your point... I tried helping you out earlier, but your response left me not caring a lot whether or not you solved your problem or not. I do appreciate you taking the time to help, even if your answer wasn't directly useful to me. I realize what I'm looking for is a bit esoteric. "What you are trying to do is impossible" is a totally acceptable answer - I am really just trying to understand why Oracle makes this impossible. The database-specificity of cursor.var() makes sense to me, idiomatically, but the restricted size of query results seems odd. For example, if I want to 'delete...returning...into...' a million rows, rather than the default allowed ~1000 or so, how can I do that? Would a pipelined procedure with PIPE ROW address this problem, and the general expectation is just that I'd be able to put such a procedure into my schema? -glyph ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 _______________________________________________ cx-oracle-users mailing list cx-...@li... https://lists.sourceforge.net/lists/listinfo/cx-oracle-users ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ GEHE Informatik Services GmbH & Co. KG, Sitz: Stuttgart, AG Stuttgart, HRA 12167, UST-IdNr. DE 811 655 252 Persönlich haftende Gesellschafterin: GEHE Pharma Handel GmbH, Sitz: Stuttgart, AG Stuttgart, HRB 14591, Geschäftsführer: André Blümel (Vorsitzender), Rainer Baumgärtner, Dr. Peter Schreiner Weitere Gesellschafter: GEHE Informatik Services-Verwaltungs GmbH, Sitz: Stuttgart, AG Stuttgart, HRB 15843 Geschäftsführer: Rainer Baumgärtner, Dr. Stefan Grill ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X