is there any way to link 2 stored procedures in a crystal reports?
I read that a stored procedure cannot call another stored procedure in a crystal report?
You should be able to do so in either the database 'expert' or within a command. However, the JOIN will be done in Crystal Reports WhileReadingRecords.
If that doesn't work for some reason, embed the second SP in a subreport, then link the main report to the subreport.
Neither of these approaches are terribly efficient. You should consider combining the queries in a way that they can be used by CR in an efficient manner.
Stored procedures, in my opinion, should be avoided in reporting, as they:
add complexity
increase maintenance costs
don't result in significant performance gains when compared to a well-structured query
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.
I am creating an SSRS report that returns data for several "Units", which are all to be displayed on a row, with Unit 1 first, to its right Unit 2 data, etc.
I can either get all this data using a Stored Proc that queries the database using an "IN" clause, or with multiple targeted ("Unit = Bla") queries.
So I'm thinking I can either filter each "Unit" segment with something like "=UNIT:[Unit1]" OR I can assign a different Dataset to each segment (witht the targeted data).
Which way would be more "performant" - getting a big chunk of data, and then filtering the same thing in various locations, or getting several instances/datasets of targeted data?
My guess is the latter, but I don't know if maybe SSRS is smart enough to make the former approach work just as well or better by doing some optimizing "behind the scenes"
I think it really depends on how big the big chunk of data is. My experience has been that SSRS can process quite a large amount of data after it comes back from the database, and it does it quickly. If the report is going to aggregate the data in the end, I try to do as much of that as I can on the database end. The reason, usually the database server has more resources to do all that work. But, if the detail is needed, and you can aggregate on the report server end easily enough, pull 10K records and do it to it.
I lean toward hitting the database as few times as possible, but sometimes it just makes sense to get the data I need with individual queries. I have built reports with over 20 datasets, each for very specific measures that just didn’t union up really well. Breaking it up like this took the report run time from 3 minutes, to 20 seconds.
Not a great answer if you were looking for which exact solution to go with. It depends on the situation. Often, trial and error gets you to the answer for the report in question.
SSRS is not going to do any "optimizing" and the rendering requirements sound trivial, so you should probably consider this as SQL query issue, not really SSRS.
I would expect the single SELECT with an IN clause will be faster, as it will require fewer I/Os on the database files. An SP is not required, you can just write a SELECT statement.
A further benefit is that you will be left with N-times less code to maintain (where N = the number of Units), and can guarantee the consistency of the code/logic across Units.
Please could someone help me with this. I am using Report Builder for Delphi. In my code I use multiple SQL queries in my dataset. In Report Builder I have DBText component which refers to my SQL queries. When I run my SQL queries in IBExpert I get the correct result but when I put it into Delphi code and setup the report, it does not do what I want it to do.
What must happen is that it must show on the report data line by line for the sales of different stores. EG: Store one and the value
Store two and the value etc..
Could some advise me please? Thank you very much.
I assume your are using ReportBuilder by Digital Metaphors.
You need to place your DBText components in a subreport and link this subreport to your pipeline. This way, the report knows to iterate through your pipeline and for each row in your dataset to print a line as defined in your subreport.
Digital Metaphors has quite a good wiki for all kinds of tutorials. See http://www.digital-metaphors.com:8080/index.php?title=Data_Access/Fundamentals/Data_Traversal&highlight=subreport for an explanation of data traversal within reports.
What is the difference between Stored Procedures and Prepared Statements... And which one is better and why...!! I was trying to google it but haven't got any better article...
Stored procedures are a sequence of instructions in PL/SQL language. Is a programming language implemented by some DBMS, that lets you store sequences of queries frequently applied to your model, and share the processing load with the application layer.
Prepared statements are queries written with placeholders instead of actual values. You write the query and it is compiled just once by the DBMS, and then you just pass values to place into the placeholders. The advantage of using prepared statements is that you enhance the performance considerably, and protect your applications from SQL Injection.
The difference is you cant store prepared statements. You must "prepare" them every time you need to execute one. Stored procedures, on the other hand, can be stored, associated to a schema, but you need to know PL/SQL to write them.
You must check if your DBMS supports them.
Both are very usefull tools, you might want to combine.
Hope this short explanation to be useful to you!
The other answers have hinted at this, but I'd like to list the Pros and Cons explicitly:
Stored Procedures
PROS:
Each query is processed more rapidly than a straight query, because the server pre-compiles them.
Each query need only be written once. It can be executed as many times as needed, even across different sessions and different connections.
Allows queries to include programming constructs (such as loops, conditional statements, and error handling) that are either impossible or difficult to write in SQL alone.
CONS
Require knowledge of whatever programming language the database server uses.
Can sometimes require special permissions to write them or call them.
Prepared Statements
PROS
Like stored routines, are quick because queries are pre-compiled.
CONS
Need to be re-compiled with each connection or session.
To be worth the overhead, each prepared statement must be executed more than once (such as in a loop). If a query is executed only once, more overhead goes into preparation of the prepared statement than you get back since the server needs to compile the SQL anyway, but also make the prepared statement.
For my money, I'd go with Stored Procedures every time since they only need to be written and compiled once. After that, every call to the procedure leads to saved time, whether you're on a new connection or not, and whether you're calling the procedure in a loop or not. The only downside is needing to spend some time learning the programming language. If I didn't have permissions to write stored procedures, I would use a prepared statement, but only if I had to repeatedly make the same query multiple times in the same session.
This is the conclusion I've come to after several months of off-and-on research into the differences between these two constructs. If anyone is able to correct bad generalizations I'm making, it will be worth any loss to reputation.
A stored Procedure is stored in the DB - depending on which DB (Oracle, MS SQL Server etc.) it is compiled and potentially prepared optimized when you create it on the server...
A prepared statement is a statement which is parsed by the server and an execution plan is created by the server ready for execution whenever you run the statement... usually it makes sense when a statement is run more than once... depending on the DB server (Oracle etc.) and even sometimes configuration options these "preparation" are either session-specific or "global"...
There is no "better" when you compare these two since they have their specific use cases...
hi all
We do know that CommandType property of a SqlCommand object has 3 options: TableDirect, Text and StoredProcedure or "SP".
Knowing that "SP" has benefits over two other options, my question is do you make lots of SP in your own systems?
Or What solution do you have instead of creating SP?
Thank you
Aside of creating Stored Procedures you can use Object Relational Mapping
Such as:
linq to sql
Nhibernate
Entity Framework
Data Access :SP's vs ORMs
Choose the best way that suits you.
In all production system I used SPs and pure ADO.NET Core to access the data. Systems range from having 100-300 tables and about 500-1000 stored procedures.
Most of the Data Access code is generated using a tool. I've posted the source code and sample application on my blog if you're interested in using/modifying it. The tool can generate over 100,000 lines of code in about 20-25 seconds going against a database with about 750 stored procedures.
Data Access Layer - Code Gen
Of course if you're no familiar with Databases, data modeling/design and stored procedures you're probably better off using Linq to SQL or EF4 (Entity Framework version 4) or similar. If you need brute force performance then ADO.NET core along with Stored procedures is the way to go.
Re: your first question
When you go down the path of stored procedures, the number of stored procedures begins to grow continually for the life of the project. Outside of the basic CRUD operations, each stored procedure tends to be tightly bound to a particular problem and not very re-usable. A rule of thumb is that I can expect 8-12 stored procedures for each data table (excluding reference or code tables, such as the list of states or countries).
The very large number of procs makes naming conventions very important so that you can find anything without constantly visually re-scanning the whole list of 400-500 procs.
Re: your second question
There are a lot of ugly things that happen with sql written inside of strings inside of C# or VB.NET -- it's error prone, ugly, etc.
Linq, nHybernate and many others exist, but the "concept count" (the number of things you need to learn to start being productive), is much higher than learning how to write a good stored procedure executer in C#.
I try to make sure that stored procedures are only created for database functionality - not business logic.
It's Database Functionality when I have some database architecture that's a bit obscure and I want to hide that from callers.
It's Business Logic when it is simply the way in which my application adds or updates or how much validation they do, etc., etc.