Apologies, I cannot provide a reduced data case for the moment. But here is a general question.
I have been using, since SQL Server 2005, thru an application using ADO with OLE DB, a Multi-Statements Table Value Function with Recursive CTE without problems.
With SQL Server 2019 performance became a problem. I then re-wrote the function as In-line Table Value Function and regain performance and functionality when used in SQL Server Management Studio.
When using in the application the first execution of a simple query with this In-line TVF returns an empty or closed recordset. got asserts in atldbicli.h. Subsequent executions of the same query return proper recordset. When I replace the select statement on the CTE by a static select statement of values, the recordset is being populated.
Any clue? axis of research , proposals? Thanks in Advance.
It appears we were using an outdated version of ADO.
Related
This question is inspired by this.
As stated, I don't want a solution from PL/SQL. I want a 1 or 2 SQL statements that will check for table existence and if its not exist - create it.
Such statement(s) will be plugged into C++ application (not a script) and so I want a plain SQL solution. If such solution is not exist (please say so), I'd like to have a simple string I can plug into C++ code and use either SQLExecute() or a native Oracle client API to execute such a string.
Trying to google for a solution I am getting a results that can be used either in the shell script or a stored procedure. As I explain here and in the previous question - my situation is completely different - I work in C++ and want an appropriate solution.
There is no single SQL statement that will create a table only if it does not exist in Oracle 11g.
It is not obvious to me why you're objecting to a PL/SQL based solution. If you're using raw ODBC calls in C++, you can pass a PL/SQL block to SQLPrepare just as you would pass a plain SQL statement. Given that PL/SQL blocks work almost exactly like a pure SQL statement, it would be unusual to categorically reject a PL/SQL based solution.
If you are going to categorically reject PL/SQL, you can certainly take the logic from any of the PL/SQL based solutions and implement that in a couple of SQL statement executed from your application. For example, you can query dba_| all_| user_tables (depending on your privileges, whether you are creating tables in other schemas, etc.) to determine whether the table exists and then conditionally execute your DDL
select owner, table_name
from dba_tables
where owner = <<schema that will own the table>
and table_name = <<name of the table>>
If that returns no rows you can then execute your DDL.
Of course, you can also just execute your DDL statement and catch the ORA-00955 name is already used by an existing object error in C++.
Oracle Forms 10g - 'NULLS' is not accepted.
In program unit(PL/SQL Code) I use NULLS FIRST and its throwing error.
Encountered the symbol NULLS
select line_id
from oe_order_lines_all
where rownum <5
order by line_id NULLS FIRST;
kindly help
I am not familiar with forms, but a simple workaround (if it works) is to modify the order by clause. For example, assuming the line id's are positive, or at least non-negative, you could
order by nvl(line_id, -1)
The flavour of PL/SQL and SQL used in Forms is different and somewhat older than the one available in the database. Being able to run code on the database does not mean it will run without changes in Forms. Analytic functions is an example of a newer SQL feature which is missing in Forms. But you can always put your code into a PL/SQL package in the database and call it from your forms code.
I'm used to Microsoft SQL Server, where the last SELECT query of a stored procedure determines what is returned.
In Oracle, I'm always using a SYS_REFCURSOR OUT parameter to return data from queries.
Are there other options of returning data from SELECT queries in Oracle stored procedures?
How about SELECT queries that select only one row? Is a SYS_REFCURSOR still necessary?
EDIT: I need to know the answer for Oracle 11g R2 (should have mentioned that explicitly instead of just in the tags).
Until now Oracle has not supported the SQL Server style of procedures implicitly returning a result set, you have had to explicitly return something - which could be a SYS_REFCURSOR or a collection or whatever.
In Oracle 12C a new feature has been added called Implicit Statement Results, which is designed to emulate the SQL Server way of working. However, this is really intended to support migration of existing code from SQL Server; for fresh Oracle development you would be best advised to learn the way Oracle normally does things.
Oracle PL/SQL Procedures can return all the supported basic datattype( date,varchar2,number) plus complex ( records, tables, varray)
Another option is the pipelined function, in which you call the function as:
select ...
from table(my_function(param1 => 1, ...))
See docs for details.
Just for clarifying, ORACLE procedures cannot 'RETURN" per se, a SYS_REFCURSOR OUT parameter is more like changing the value of a variable reference inside the procedure.
Apart from SYS_REFCURSOR, if you are returning only one row of a table, say EMPLOYEE, you can also define a record as EMPLOYEE%ROWTYPE and use it as a OUT type.
Or like:
PROCEDURE pr_proc (v_input in number
v_emp_row out EMPLOYEE%ROWTYPE )
IS
I just created a stored procedure in MS SQL DB using TOAD.
what it does is that it accepts an ID wherein some records are associated with, then it inserts those records to a table.
next part of the stored procedure is to use the ID input to search on the table where the items got inserted and then return it as the result set to the user just to confirm that the information got inserted.
IN TOAD, it does what is expected. It inserts date and returns information using just the stored procedure.
IN Oracle SQL developer however, it does the insert and it ends at that. It seems to not execute the 2nd part of the stored procedure which is a select stmt.
I just have a feeling that this is because of the jdbc adapter. Also why I'm asking is because I'm using a reporting tool Pentaho Report Designer and it would really make it easier if I can do 2 things at the same time. Pentaho Report Designer is also using jdbc adapters, not a coincidence maybe?
But if there are other things that I can tweak I'd really appreciate it.
This is a guess, but worth considering...
There are things called "Batches", where are sets of SQL Statements that are all sent to the server at once, and executed by the server as one set of statements, within a single server-side session. Sending a set of sql statements to the server as a batch will often result in different results than if you sent them one at a time, where each statement is executed in its own session.
I haven't used Toad (or Oracle) in a while, but as I recall, it dealt with batches differently than the other ide I used. If the second statement in your set is relying on being in the same session as the first, and in one ide it is in a separate session, then this might explain what is happening.
How do I debug a tsql Stored procedure. I have tried the following link.
http://msdn.microsoft.com/en-us/library/ms241871(v=vs.80).aspx
But I am unable to hit the break point. Is there a better way to debug. My environment is
Sql Express 2008, Visual Studio 2010
I have found the debugger in SQL Managment studio unreliable as it's so dependant on having the correct permissions on the db server which are not always available.
One alternate method I use is to convert the stored proc into a long query. I start by moving any parameteres to variable declarations and set their values. For examples the following
ALTER PROCEDURE [dbo].[USP_ConvertFinancials] (#EffectiveDate datetime, #UpdatedBy nvarchar(100))
AS
BEGIN
DECLARE #PreviousBusinessDay datetime
would become
DECLARE #Value int,
, #EffectiveDate datetime = '01-Jan-2011
, #UpdatedBy nvarchar(100) = 'System'
This allows me to run the queries within the stored procedure starting from the top. As I move down through the queries, I can check the values of variables by simply selecting them and rerunning the query from the top:
SELECT #Value
I can also comment out the INSERT portion of INSERT-SELECT statements to see what is being inserted into tables and table variables.
The bug in the stored proc usually becomes quite evident using this method. Once I get the query running correctly I can simply copy the code to my proc and recompile.
Good luck!
You can try out Sql Profiler, it does not allows a classical debugging like "break at this point" but gives you an information in great detail about what is going on on each step of a query/SP execution.
Unfortunately Microsoft does not provide it with Express Edition version of Sql Server.
BUT :) There is a good (relatively because it does not provide a lot of filtering criterias which exists in Microsoft's one) and free alternative - SQL Server 2005/2008 Express Profiler.
Debug a stored procedure.
check the logic whether it makes sense or not.
use break point to help find issues.
try to do the modular design as per complex process.
divide the task into multiple simple ones.
use a master stored procedure to take control on the top, and use several child stored procedures to do the job step by step.
As per the optimization, use execution plan, SS Profiler and DTA tools.