I expend a lot of time trying to retrieve data from a Stored Procedure, here is the code
CREATE PROCEDURE aprocedure(
IN idin CHAR,
OUT returnvalue CHAR)
AS:
SET returnvalue=
(SELECT something
FROM sometable
WHERE id=idin)
I could create it, with no problems, but when I tried to call it like this:
call someprocedure('theid', ?)
Error -313 kept poping out, I did my homework and check the web, IBM forums were no help at all, I couldnt find any documentation, specifications, or anything that make this more clear, also SQL error code -313 means that the number of parameters in the procedure does not match the number of parameters you're using when you call it. So, after too much research, I started thinking that DB2 with JDBC driver and or SQuirreL have trouble when returning OUT values, (I also installed a DB2 CTL client, created a local database, created a table, created the procedure, I called, and everything worked nicely) so I change my code to this (to use a Result Set instead of an OUT):
CREATE PROCEDURE someprocedure(IN idin CHAR (22))
DYNAMIC RESULT SETS 1
P1: BEGIN
DECLARE cursor1 CURSOR WITH RETURN FOR
SELECT something FROM sometable WHERE id=idin;
OPEN cursor1;
END P1
aaaaaaaaaaaand NOTHING, SQuirreL gave me some error codes, when trying to create it, so... I enter that same code in Aqua Data Studio 4.7, and worked like a charm, I call the procedure from Aqua Data like this:
call someprocedure('theid');
and it returned what was supposed to return, I tried that same sentence with SQuirreL...
and it WORKED too !!
Im sure that my sintaxys was correct all along, even with the OUT type of return, so, my question, finally is this.
Does SQuirreL check the input you enter before passing it to the JDBC?
Also
Where do I can find how exactly DB2 is altering SQL code?? because we all know that all DBM change the SQL a bit, but MySQL have great documentation... and i honestly couldnt find any good one on DB2, also im talking about "pure" SQL since in DB2 you can enter stored procedures in C , Java etc...
Related
I've been trying to use a Stored Procedure in Datazen, but every time I build the dataset, it doesnt actually return any data (yet doesnt give me an error and does give me the column headings). I've tried the same query in SSRS 2016 and the new mobile report builder, and both work a charm, but Datazens just not having it.
USE [SSRS_Reports_SPs]
EXEC [dbo].[Test]
Really, I just want to know if its possible in datazen, and if so what I might be doing wrong.
Cheers
Earlier we were using Sybase as the back end. Now we are migrating to SQL server where as front end remains the same i.e. PowerBuilder.
Issue :
I have a DataWindow code which takes two retrieval arguments adt_from_date and adt_to_date. Both Date format. This works fine for PB-Sybase combination, but throws an error 37000 for SQL server.
Here is our code. If I hard-code the dates. i.e. for e.g. if I replace :adt_from_date by '20141001'. The code works fine.
SELECT A.MEMBER_NO AS 'MEMBER_NO',
ROUND(SUM(TRANSACTION_CHARGES),2) as 'AMOUNT',
SUBSTRING(DATENAME(MM, :adt_from_date ),1,3) +'-'+substring(convert(varchar,datepart(YY, :adt_from_date )),3,2) as 'REASON'
FROM TRAN_SERVICE_TAX_DRV A,
MEMBER_MASTER B
WHERE A.MEMBER_NO = B.MEMBER_NO
AND A.TRADE_DATE BETWEEN :adt_from_date AND :adt_to_date
GROUP BY A.MEMBER_NO
Please suggest something on this.
I'd suggest you look at the error text being loaded into the transaction instead of just the number; it will probably be much more helpful. If we're talking about SQLState 37000, that doesn't narrow it down much.
If that doesn't shed some light on it, I'd look at tracing either on the PowerBuilder side, or on the database side. Starting on the PB side probably makes most sense. If you're just running this DataWindow from the IDE, the trace is just a checkbox on the connection properties. If in the app, replace your "DBMS='xxx'" with "DBMS='tra xxx'" (there are other options described in the Connecting to your Database manuals).
Good luck.
I'm getting a little confused about using parameters with SQL queries, and seeing some things that I can't immediately explain, so I'm just after some background info at this point.
First, is there a standard format for parameter names in queries, or is this database/middleware dependent ? I've seen both this:-
DELETE * FROM #tablename
and...
DELETE * FROM :tablename
Second - where (typically) does the parameter replacement happen? Are parameters replaced/expanded before the query is sent to the database, or does the database receive params and query separately, and perform the expansion itself?
Just as background, I'm using the DevArt UniDAC toolkit from a C++Builder app to connect via ODBC to an Excel spreadsheet. I know this is almost pessimal in a few ways... (I'm trying to understand why a particular command works only when it doesn't use parameters)
With such data access libraries, like UniDAC or FireDAC, you can use macros. They allow you to use special markers (called macro) in the places of a SQL command, where parameter are disallowed. I dont know UniDAC API, but will provide a sample for FireDAC:
ADQuery1.SQL.Text := 'DELETE * FROM &tablename';
ADQuery1.MacroByName('tablename').AsRaw := 'MyTab';
ADQuery1.ExecSQL;
Second - where (typically) does the parameter replacement happen?
It doesn't. That's the whole point. Data elements in your query stay data items. Code elements stay code elements. The two never intersect, and thus there is never an opportunity for malicious data to be treated as code.
connect via ODBC to an Excel spreadsheet... I'm trying to understand why a particular command works only when it doesn't use parameters
Excel isn't really a database engine, but if it were, you still can't use a parameter for the name a table.
SQL parameters are sent to the database. The database performs the expansion itself. That allows the database to set up a query plan that will work for different values of the parameters.
Microsoft always uses #parname for parameters. Oracle uses :parname. Other databases are different.
No database I know of allows you to specify the table name as a parameter. You have to expand that client side, like:
command.CommandText = string.Format("DELETE FROM {0}", tableName);
P.S. A * is not allowed after a DELETE. After all, you can only delete whole rows, not a set of columns.
I'm using a DB2 database and I'm hoping for a query which will iterate over all stored procedures in a single database and print out the source code of each. No fancy formatting or performance requirements.
The reason for this (in case there's a better way of doing it) is I'm trying to track down usages of a particular table in our stored procs, so I want to be able to do a simple text search through all of them.
Also, I've got access to SQuirreL SQL client if anyone knows of a way via that.
Ah, figured it out. For other's reference:
select ROUTINENAME, TEXT from syscat.routines
where definer not in ('SYSIBM') AND ROUTINESCHEMA='databaseName'
I know this is old, but your answer started me on the right track. We are also using DB2, but don't have syscat.routines visible to us. However we do have SYSIBM.SYSROUTINES and that allows similar by doing
SELECT SCHEMA,
NAME,
TEXT
FROM SYSIBM.SYSROUTINES
WHERE SCHEMA = '<SCHEMA>'
and NAME = '<NAME>'
FOR FETCH ONLY WITH UR;
Is there a way to run a query and then have SQL Server management studio or sqlcmd or something simply display the datatype and size of each column as it was received.
Seems like this information must be present for the transmission of the data to occur between the server and the client. It would be very helpful to me if it could be displayed.
A little background:
The reason I ask is because I must interface with countless legacy stored procedures with anywhere from 50 to 5000+ lines of code each. I do not want to have to try and follow the cryptic logic flow in and out of temp tables, into other procedures, into string concatenated eval statement and so on. I wish to maintain no knowledge of the implementation, simply what to expect when they work. Unfortunately following the logic flow seems to be the only way to figure out what exactly is being returned without trying to infer what the actual types of the data string representations om management studio studio or from the native type in .net for example.
To clarify: I am not asking about how to tell the types of a table or something static like that. I'm pretty sure something like sp_help will not help me. I am asking how to tell what the sql server types (ie varchar(25), int...) are of what I have been given. Additionally, changing the implementation of the sprocs is not possible so please consider that in your solutions. I am really hoping there is a command I have missed somewhere. Much appreciation to all.
Update
I guess what I am really asking is how to get the schema of the result set when the result set originates from a query using a temp table. I understand this to be impossible but don't find much sense with that conclusion because the data is being transmitted after all. Here is an example of a stored procedure that would cause a problem.
CREATE PROCEDURE [dbo].[IReturnATempTable]
AS
Create table #TempTable
(
MyMysteryColumn char(50)
)
INSERT #TempTable (
MyMysteryColumn
) VALUES (
'Do you know me?' )
select TOP 50 * FROM #TempTable
What will you do about stored procedures which return different result sets based on their parameters?
In any case, you can configure a SqlDataAdapter.SelectCommand, along with the necessary parameters, then call the FillSchema method. Assuming that the schema can be determined, you'll get a DataTable configured with correct column names and types, and some constraints.
A bit of a long shot, try messing around with SET FMTONLY ON (or off). According to BOL, this "Returns only metadata to the client. Can be used to test the format of the response without actually running the query." I suspect that this will inlcude what you're looking for, as BCP uses this. (I stumbled across this setting when debugging some very oddball BCP problems.)
Could you append another select to your procedure?
If so you might be able to do it by using the sql_variant_property function.
Declare #Param Int
Set #Param = 30
Select sql_variant_property(#Param, 'BaseType')
Select sql_variant_property(#Param, 'Precision')
Select sql_variant_property(#Param, 'Scale')
I posted that on this question.
I am asking how to tell what the sql
server types (ie varchar(25), int...)
are of what I have been given
You could then print out the type, precision (i.e. 25 if its VarChar(25)), and the scale of the parameter.
Hope that helps... :)
If you are not limited to T-SQL, and obviously you don't mind running the SPs (because SET FMTONLY ON isn't fully reliable), you definitely CAN call the SPs from, say C#, using a SqlDataReader. Then inspect the SqlDataReader to get the columns and the data types. You might also have multiple result sets, you you can also go to the next result set easily from this environment.
This code should fix you up. It returns a schema only dataset with no records. You can use this Dataset to query the columns' DataType and any other metadata. Later, if you wish, you can populate the DataSet with records by creating a SqlDataAdapter and calling it's Fill method (IDataAdapter.Fill).
private static DataSet FillSchema(SqlConnection conn)
{
DataSet ds = new DataSet();
using (SqlCommand formatCommand = new SqlCommand("SET FMTONLY ON;", conn))
{
formatCommand.ExecuteNonQuery();
SqlDataAdapter formatAdapter = new SqlDataAdapter(formatCommand);
formatAdapter.FillSchema(ds, SchemaType.Source);
formatCommand.CommandText = "SET FMTONLY OFF;";
formatCommand.ExecuteNonQuery();
formatAdapter.Dispose();
}
return ds;
}
I know this is an old question, I found it through a link from SqlDataAdapter.FillSchema with stored procedure that has temporary table. Unfortunately, neither question had an accepted answer, and none of the proposed answers were able to resolve my issue.
For the sake of brevity, if you are using SQL Server 2012 or later, using the following built-in functions will work in most situations:
sys.dm_exec_describe_first_result_set
sys.dm_exec_describe_first_result_set_for_object
However, there are some cases in which these functions will not provide any useful output. In my case, the problem was more similar to the question linked above and therefore, I believe the solution is more appropriately answered under that question. My answer can be found here.