Is it possible to define user defined functions in a stored procedure in DB2? I need quite a few of them and most of them are only needed in one stored proc. Is it possible to scope them to the stored procedure so that I don't have to define them at the database level?
No, you can't do this. However, if you use modules (available in DB2 9.7 and newer), you can define functions within the module aren't availble for use outside of the module.
Here's a good article covering the basics of modules, written by the lead SQL architect for DB2.
Related
Hy all,
this is my first question on stackoverflow, so let me know if something is wrong.
Howerver, I need to know if is it possible to read a dataset, defined with a DD name declared in a COBOL program, from a Java Stored Procedure under DB2.
The program flow is:
- a JCL invoke a STORED PROCEDURE
- the STORED PROCEDURE invoke the jar
- the jar try to open the data set through the DD name
I tried to use ZFile class from jZos library but the Java code can't see neither the DD name and the relative file on z/OS.
My doubt is: There is no way to accomplish this task because the JVM on DB2 runs in an isolated environment or there is a specific class/procedure to reach the data set?
Thanks in advance!
There is a significant difference between "is it possible," "is it allowed," and "is it a good idea."
Because you know the file name I believe it may be possible to achieve your goal via dynamic allocation of the file associated with the DD. The javadoc for ZFile indicates it "includes an interface to BPXWDYN (text based interface to MVS dynamic allocation)."
Whether this is allowed in your IT shop is a question for your architecture staff and DB2 Systems Programmers (the people responsible for installing, configuring, and performance of DB2). Just because something is possible does not mean it is allowed - there may be performance or security or audit considerations.
Even if it turns out this architecture is possible and allowed, it may be that there are better solutions. Talk to your architecture staff and z/OS and DB2 Systems Programmers about your requirements and why you wish to pursue this particular solution. Ask them for suggestions on improvements which still implement your requirements.
For example, if you intend to execute this stored procedure one million times in a batch job, and to dynamically allocate the file, open it, read its contents, close it, and then deallocate it for each execution - that is unlikely to perform well and is likely to have an adverse impact on the other applications which make use of DB2 stored procedures. Perhaps storing the contents of the file in a DB2 table is a better solution - I cannot say because I do not know your business requirements or the context of the rest of your application, I merely bring it up as an example.
For example, the original SP include several IN parameters and SQLs. Now, I used java application which implemented each SQLs and used Oozie to simulate the whole process/workflow in Oracle SP, not sure if it is the right way. Could you please provide some advices?
Thanks in advance!
You can use CTE (Common Table Expressions) to model your queries. Stored procedures as database objects are not supported in Hive/Impala yet. You may want to have a look here
I'm not too big of a fan of direct entity mappers, because I still think that SQL queries are fastest and most optimized when written by hand directly on and for the database (using correct joins, groupings, indexes etc).
On my current project I decided to give BLToolkit a try and I'm very pleased with its wrapper around Ado.net and speed so I query database and get strong type C# objects back. I've also written a T4 that generates stored procedure helpers so I don't have to use magic strings when calling stored procedures so all my calls use strong types for parameters.
Basically all my CRUD calls are done via stored procedures, because many of my queries are not simple select statements and especially my creates and updates also return results which is easily done using a stored procedure making just a single call. Anyway...
Downside
The biggest drawback of BLToolkit (I'd like everyone evaluating BLToolkit to know this) aren't its capabilities or speed but its very scarce documentation as well as support or lack thereof. So the biggest problem with this library is doing trial and error to get it working. That's why I also don't want to use too many different parts of it, because the more I use the more problems I have to solve on my own.
Question
What alternatives do I have to BLToolkit that:
support use of stored procedures that return whatever entities I provide that are not necessarily the same as DB tables
provide a nice object mapper from data reader to objects
supports relations (all of them)
optional (but desirable) support for multiple result-set results
doesn't need any special configuration (I only use data connection string and nothing else)
Basically it should be very lightweight, should basically just have a simple Ado.net wrapper and object mapper.
And the most important requirement: is easy to use, well supported and community uses it.
Alternatives (May 2011)
I can see that big guns have converted their access strategies to micro ORM tools. I was playing with the same idea when I evaluated BLToolkit, because it felt bulky (1.5MB) for the functionality I'd use. In the end I decided to write the aforementioned T4 (link in question) to make my life easier when calling stored procedures. But there are still many possibilities inside BLToolkit that I don't use at all or even understand (reasons also pointed out in the question).
Best alternative are micro ORM tools. Maybe it would be better to call them micro object mappers. They all have the same goals: simplicity and extreme speed. They are not following the NoSQL paradigm of their big fellow ORMs, so most of the time we have to write (almost) everyday TSQL to power their requests. They fetch data and map them to objects (and sometimes provide something more - check below).
I would like to point out 3 of them. They're all provided in a single code file and not as a compiled DLL:
Dapper - used by Stackoverflow itself; all it actually does it provides generic extension methods over IDbConnection which means it supports any backing data store as long there's a connection class that implements IDbConnection interface;
uses parametrised SQL
maps to static types as well as dynamic (.net 4+)
supports mapping to multiple objects per result record (as in 1-1 relationships ie. Person+Address)
supports multi-resultset object mapping
supports stored procedures
mappings are generated, compiled (MSIL) and cached - this can as well be downside if you use huge number of types)
Massive - written by Rob Connery;
only supports dynamic type mapping (no support in .net 3.5 or older baby)
is extremely small (few hundreds of lines of code)
provides a DynamicModel class that your entities inherit from and provides CRUD functionaly or maps from arbitrary baremetal TSQL
implicit paging support
supports column name mapping (but you have to do it every time you access data as opposed to declarative attributes)
supports stored procedures by writing direct parametrised TSQL
PetaPoco - inspired my Massive but with a requirement to support older framework versions
supports strong types as well as dynamic
provides T4 template to generate your POCOs - you'll end up with similar classes as big fellow ORMs (which means that code-first is not supported) but you don't have to use these you can still write your own POCO classes of course to keep your model lightweight and not include DB only information (ie. timestamps etc.)
similar to Dapper it also compiles mappings for speed and reuse
supports CRUD operations + IsNew
implicit paging support that returns a special type with page-full of data + all metadata (current page, number of all pages/records)
has extensibility point for various scenarios (logging, type converters etc)
supports declarative metadata (column/table mappings etc)
supports multi object mapping per result record with some automatic relation setting (unlike Dapper where you have to manually connect related objects)
supports stored procedures
has a helper SqlBuilder class for easier building TSQL statements
Of all three PetaPoco seems to be the liveliest in terms of development and support most of the things by taking the best of the other two (and some others).
Of all three Dapper has the best real-world usage reference because it's used by one of the highest traffic sites on the world: Stackoverflow.
They all suffer from magic string problem because you write SQL queries directly into them most of the time. But some of this can be mitigated by T4, so you can have strong typed calls that provide intellisense, compile-time checking and re-generation on the fly within Visual Studio.
Downside of dynamic type
I think the biggest downside of dynamic types is maintenance. Imagine your application using dynamic types. Looking at your own code after a while will become rather problematic, because you don't have any concrete classes to observe or hang on to. As much as dynamic types are a blessing they're as well a curse on the long run.
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
What are the pros and cons to keeping SQL in Stored Procs versus Code
What would be appropriate scenario when stored procedures should be used?
I stumbled upon implementation where almost whole data manipulation was handled by store procedures, even simplest form of INSERT/DELETE statements were wrapped and used via SP's.
So, what's the rationale for using stored procedures in general?
Sorry for such a beginners question..
Outwith the reasons #Tom has already pointed out which are probably the most important (Speed/Security) I would also say that another good reason to use Stored Procedures is code re-use. If you find yourself writing the same SQL all over the place its usually a sign that it should be a stored procedure. Also, another good reason is it allows not only developers, but DBA's the ability to change/add new procedures if required.
Two reasons I know of:
Security
The stored procedures are secure from attacks such as SQL injection attacks
Speed
Stored procedures are sometimes precompiled which makes execution faster.
for me it is the same question as whether or not to create a function/method while programming.
For example if the functionality is needed to be repeated in many places, or is going to be called more than once then it should be in a function.
It allows you to keep data access near the data. I have worked in systems where all data access was stored procs with server side wrapper functions. It was pretty clean ( but not as 'cool' as an ORM )
When other systems need to access your data and you need to provide an API at the database - Procs would be a way to allow you control over what/how they access it.
I am answering from an enterprise perspective.
two types of designs,
Put all/most of business logic on DB server
Put all/most of Business logic on application server.
In #1, you use Stored procedure to implement your application logic instead of the programming language.
In #2, you use the programming language to implement the logic, and it is easier to debug and allow code reuse and all other features that any programming language provides.
If you are a DB guru (and your app is mid to small), choose the first approach, otherwise choose second approach.
BTW, you will find .NET app uses the first approach, and Java app followed the second.
With newer versions of DB2 you can write stored procedures in SQL or you can create procedures in Java (or other languages) that can then be added to the database and called just like SQL procedures. I'm wondering what the the pros and cons of each method are. I'm specifically interested in comparing those two types of procedures, not debating procedures versus external code which I think has already been covered. Here is what I've come up with so far:
SQL:
Better performance for basic SQL functionality
Less verbose for simple logic, i.e. you can run SQL directly
No extra compile step - just create procedure ...
Java:
More structured and full-featured code (classes, objects, reuse, libraries)
Better resources for help both in terms of programmers and documentation
Any other thoughts?
Not just Java but any procedural language: procedural, that's the key.
DB2 is a relational algebra, not a programming language. If you need to do something complex, it's better to use a procedural language than try to bend SQL into something it's not meant to be.
We actually use REXX for our DB2/z work but I've seen guys here use bash on the mainframe for quick prototyping. Some who only use SQL create all these horrible temporary tables for storing things that are best kept in structures and away from the DB.
My thoughts are that complexity is the only differentiating factor between using SQL directly in a stored procedure and a procedural approach. We have two rules of thumb when making these decisions.
1/ If a unit of work requires more than two trips to the database, we make it a stored procedure.
2/ If a stored procedures creates a temporary table, then we use a procedural language to do it.
You may already have found this but just in case and for any others that swing by here there's an IBM Redbook on SProcs and the changes for DB2 v9 available at
DB2 9 for z/OS Stored Procedures: Through the CALL and Beyond
which discusses the available options and their relative merits.
The advantage with the SQL stored procedures is they are portable to other Db2 UDb with minimal or no changes. But Db2 external procedures would be a better choice as you can do more with a procedural language than sql alone.
I would say cobol would be a better fit for DB2 external stored procedures than Java for the below reasons.
1). You would be able to reuse some code from existing programs. Converting a cobol sub program to a stored procedure or stored procedure to a cobol sub program is very easy to accomplish.
2). You would be able to use existing cobol development team who has functional knowledge with the system.