I'm writing a PL/1 subroutine that reads data from DB2. Depending on the input, it uses one of 3 cursors. These have to be opened, fetched, closed, etc. On every of these cursor-specific operations I have to specify its name. This leads to very redundant code, because the remaining operations are exactly the same for every case.
Is it possible to create a reference, to which I would assign the appropriate cursor? Then I could use this to perform the necessary tasks only once.
Because of safety-related restrictions, I'm not allowed to use dynamic (prepared) SQL.
And is there a reference containing all commands I can use in my EXEC SQL statements?
Thanks in advance
David
And is there a reference containing all commands I can use in my EXEC SQL statements?
IBM has documentation for DB2, which contains an SQL reference for the product.
Related
I use CTEs (common table expressions) in SQL developer to make my queries more structured, and also with the intent to create "bricks" which I can reuse in queries.
For the second purpose it would be good to keep those CTEs in a separate file, so I don't need to browse for the latest version.
Is it possible to refer to CTE in another file in Oracle's SQL developer?
I know I could create queries / views in the database and use them, but unfortunately I don't have access to that.
One way to go would be code templates in SQL Developer itself. So you could code up your most frequent CTE's and invoke them with the keyboard.
I talk about those here
But basically you code them up in the preferences, and give them a name.
Then type the name, and hit ctrl+space to invoke the template.
You can also set these up as Auto-Replace.
For what it's worth - you CAN reference code from other files using the # and ## commands. However, it will take the contents of that file and execute as a complete, standalone SQL statement or series of statements, so I don't think you can use this to achieve your goal.
I know there are tmysqlrow and tmysqlsp components available in Talend but it is fine if we use tmysqlinput to run stored procedure?
It depends on your requirements but generally you can use all of those components.
tMysqlSP
is there for convenience.
tMySqlRow
allows much more freedom.
tMySqlInput
is usually being used to get a result from the database. If you stored procedure doesn't return rows, which is sometimes the case, the following elements of the job might not run then.
So I would use one of the two first ones.
Is there a way to get SQL Compare to output all objects, specifically stored procedures, in a database and not just those that differ?
In your compare results you should see a few different groupings. One being "identical objects". That one is on the bottom of my view. I am using SQL Compare 10.
If I want it to actually script all of the objects (rather than just see them in the results), I usually create an empty database and compare to that, then filter just to stored procedures and go through the synchronization wizard.
I want to find the exact SQL statements that are generated by a Perl ORM package such as Class::DBI. I am not looking for SQL generated for simple inserts and deletes, but for row modifications that result from slightly complicated object manipulations (inserting rows in a table which is a child of a row in a parent table, for example)
Is there some way to get it?
Class::DBI uses DBI under the hood, so you can enable tracing of all SQL statements via an environment variable:
DBI_TRACE=3=dbi.log your-perl-script
Or inside of Perl, before executing any statements:
use DBI;
DBI->trace(2, 'dbi.log');
See http://metacpan.org/pod/DBI#TRACING
Since you said "such as"…
You can set the environment variable DBIC_TRACE to 1 if you are using DBIx::Class (which has a Class::DBI compatibility layer).
I need to make sure my ado.net commands don't return more than 1000-5000 rows. Is there an ADO.NET way to do this, or is it just a TSQL?
I'm calling a stored procedure, I don't control the source code in that stored procedure. Hence I was hoping there was a ADO.NET way to do it.
Before LINQ this typically was always done using a top N clause in your inline query or stored proc. With LINQ there is some cool functions called "Take" and "Skip" which provides a construct for downloading and or skipping N number of rows. Under the hood LINQ figures out the details of how to construct the inline query that yields the exact number of rows you want off the top.
[Edit]
Since you're calling a stored procedure, I'd advise just using a TOP N clause in the select statement. This is path of least resistance and IMHO is the simplest to maintain going forward since you already have the stored procedure.