I'm writing in VB.net 4.0 and using SQLExpress 2008 R2. In a DataGridView, I would like to display (no edits) data coming from multiple tables in my database. A second Grid (different data, still multiple tables) will need to allow editing and saving of data.
I understand creating a View in the database and using that as a source for the DataGridView. I also assume that there are ways to query and create a data source for the Grid totally within my VB program. Would someone explain the consequences and implications of the different approaches?
I recommend you look into LINQ to SQL for your data calls. It would be prudent for you to create a data access layer class that performs all of your data calls separate from any UI architecture you have. This allows you to maintain the data calls within the code but separated from any display logic.
Putting your queries into SQL server as views or stored procedures simplifies some of your immediate code within the application, but over time stored procedures and views become harder to maintain. Unless you have massive data load and optimization requires stored procedures, I'd recommend you investigate the usage of LINQ for making quick, atomic data calls.
I would go with the good old Stored Procedure. Write one SP, getting data for each gridviews.
Related
I manage an application built on Access with some VBA code that takes its data from:
Inputs by the user through Access forms
Tables in Sybase (that are linked through Access)
Local tables in Access
The application is used to make some financial calculations. Our calculations need a lot of conditions and are mostly some complex calculations (fractions, multiplications...)
My question is : is VBA faster than Sybase to do the calculations ?
(Please notice than when we do our calculations it takes our 3 kinds of data sources)
I was thinking about migrate all of the calculations to Sybase as some stored procedures and call it from the VBA code with parameters, and wait from an output from Sybase.
PS: another reason why I am asking that is because we consider as a long term project to migrate our Access application to a thin client(prob web-based), and if all the calculations are already on the server/database side it could maybe be easier? What do you think?
Thanks a lot for your help
IMO, I would pass the form based variables (user entry) as parameters into a stored procedure, then fetch the other variables as needed from tables within the SP. This avoids sending too much data to the client as the form is opening. This abstracts the logic from VBA code (or any specific front-end language), making it easier to eventually move to a thin layer. You can also recompile independent stored procedures as needed, instead of deploying another instance of your code (much harder usually).
If there are a lot of parameters coming from the form or local tables, consider passing them in as a structured data type within Sybase. The procedure cache within Sybase is extremely powerful and after initial compilation as fast as any other procedural language.
It depends on the calculations. Sybase will be better at doing calculations that involve grouping data, but complex calculations like fractions, etc... would be faster to do in code. Also it's just better practice to separate out business logic from data.
We are presently developing an application, let's call it APP1, which uses a SQL Database which have about 800 stored procedures, 600 tables, etc. APP1 was originally created in order to replace another application, APP0, from which we do not have source code but only SQL tables, Stored Procedures, views, etc. Previous programers of APP1 used some DB objects from this same database and added some other objects specific to APP1 because it becomes bigger than APP0. And we do not need APP0 anymore as APP1 does all what we want, and more.
So, now, we are thinking about a way to find out which objects are used by APP1 in order to remove objects which are ONLY used by APP0.
What is the best approach to discover all objects used by APP1 without having to open every single class and form?
Once we will have a complete list of these objects, it will be easy to use a program we bought which detects all dependencies for all SQL Objects specified directly from SQL and remove objects which do not return from any dependencies. Any ideas of how I could get this list without having to go through all our program that have many, many, many classes and forms?
Thanks,
Note : I know, in a perfect world, all calls to PSs and tables should be in a DAL but in the case of the application we're presently working on ... this is not our case! Yippy! (sarcastic yippy) ;)
Note 2 : This application is not using any ORM. So all queries are directly using SqlCommand. So any call to any DB objects are in string format.
You mentioned you have all the Tables, Sprocs & etc from APP0. Presumably there is a BAK of them or you can grab the original SQL objects by installing APP0 on a fresh PC.
Then use SQL Compare from RedGate to compare the Database that APP1 uses to the original APP0 Database, then you can see which objects you've added and can strip out all the redundant APP0 db objects.
You could run a trace on the database whilst the application is in use. This is likely to create a rather large amount of data, but from that you can reduce it to the procedures and or SQL statements executed by your application.
Can you guarantee that you will, or can, use all the functionality? You might want to also run something like NCover to check how much of the application code you've exercised whilst using it.
I don't have an easy answer, but here's how I'd attack it. I admit up front this would take a fair amount of time, so I'll readily yield to someone who has a better answer.
It's a two-step problem.
Step 1: Find all the dependencies within SQL. That is, find all the tables that are used to make views, and find all the tables and views that are used in stored procedures and functions. MS SQL server has a function to do this for you. With other DBs you could write some queries against information_schema (or whatever their proprietary equivalent is).
Step 2: Get a list of all the SQL statements and stored procedures executed from within your code. This should be relatively straightforward if you do not build SQL statements on the fly. Just search for all your SQLCommand objects and find what you set the query to. You could write a little program to scan your source and dump this out.
Then parse through this dump and make a list of referenced sprocs, tables, and views. Sort alphabetically and eliminate duplicates. Then add any tables or views referenced from sprocs and any tables referenced from views. Sort and eliminate duplicates again. Then you have your list.
If you do geneate SQL on the fly, I think the complexity level multiplies greatly. Then you have to work your way through code that generates SQL and pick out the table names. If there are places where table names are passed from function to function, this could get very hard. (I could imagine real nightmare scenarios, like you ask the user to type in a table name or you build a table name from pieces. Like, "dim tablename = if(dept="B17","accounting", "manufacturing") & "_" & year".)
I have read these very good questions on SO about SQL stored procedures:
When should you use stored procedures? and
Are Stored Procedures more efficient, in general, than inline statements on modern RDBMS’s?
I am a beginner on integrating .NET/SQL though I have used basic SQL functionality for more than a decade in other environments. It's time to advance with regards to organization and deployment. I am using .NET C# 3.5, Visual Studio 2008 and SQL Server 2008; though this question can be regarded as language- and database- agnostic, meaning that it could easily apply to other environments that use stored procedures and a relational database.
Given that I have an application with inline SQL queries, and I am interested in converting to stored procedures for organizational and performance purposes, what are your recommendations for doing so?
Here are some additional questions in my mind related to this subject that may help shape the answers:
Should I create the stored procedures in SQL using SQL Management Studio and simply re-create the database when it is installed for a client?
Am I better off creating all of the stored procedures in my application, inside of a database initialization method?
It seems logical to assume that creating stored procedures must follow the creation of tables in a new installation. My database initialization method creates new tables and inserts some default data. My plan is to create stored procedures following that step, but I am beginning to think there might be a better way to set up a database from scratch (such as in the installer of the program). Thoughts on this are appreciated.
I have a variety of queries throughout the application. Some queries are incredibly simple (SELECT id FROM table) and others are extremely long and complex, performing several joins and accepting approximately 80 parameters. Should I replace all queries with stored procedures, or only those that might benefit from doing so?
Finally, as this topic obviously requires some research and education, can you recommend an article, book, or tutorial that covers the nuances of using stored procedures instead of direct statements?
Consider skipping stored procedures for an ORM. Consider using:
LINQ To SQL
Entity Framework
SubSonic
You'll be writing less boiler plate ListCustomer and GetCustomerByID code when you could be adding more value to your application.
IMO, there isn't any real compelling reason to choose stored procedures with the modern toolset that we have in the Microsoft stack.
The move away from inline SQL statements is good, and an ORM will help parameterize your queries for you. You don't have to think about it.
You don't have to mess with ADO.NET objects at all. Code your data access in an object oriented fashion.
There are several compelling reasons to avoid giving table access to very many logins, including application logins, and these drive the use of stored procedures. (I generally do not ascribe any importance to using SPs for performance reasons - SQL Server caches even adhoc query plans).
Stored procedures give your database much more capability in defining its interface boundaries. In many cases, views are not sufficient to control the interface.
Any framework built solely on tables and views (note that many frameworks can build on top of SP results) is going to be severely limited in letting your database protect itself and control itself.
As a simple example, neither tables nor views can be parameterized. If you have a very large table or view and you want to enforce all users to specify a certain set of filter criteria (for instance a snapshot date or effective date), there is no way to enforce this at the database call interface. The framework can submit queries for all time. If the table/view is not exposed, and the only interface is through an SP or table-valued UDF, then the parameters to that SP or UDF MUST be provided, thus satisfying your database's need to ensure that it is used properly.
Other examples, where views may or may not work, include hiding privacy information for certain users, hiding internal keys, hiding internal implementation details, and enforcing complex security rules.
As far as scripting the creation of your database schema, including objects in the correct dependency order, there are several tools to do this (and generate change scripts), including Red Gate SQL Compare and Apex SQLScript.
Use stored procedures if you really have a performance requeriment, particularly if one stored procedures will be called thousands of times per minute. This way sql engine avoids severals steps for processing the statement. GPS Tracking systems is an example. Say you have 10000 vehicles which reports a 3 positions per minute. In this case stored procedures helps performance.
If not, instead of CRUD sql statements, use ORM features.
You missed one:
When is it better to write "ad hoc sql" vs stored procedures
My answer is: don't use stored procedures at all.
I am trying to figure out what is the 'best' (read: "your preferred method") way to generate datasets for SQL Server Reporting Services Reports (either 2005/2008):
In-report queries
Stored procedures
Views
But more than just choosing one of the above, why would you use that particular method? Also, please include your perspective (Developer/DBA/etc).
Thanks.
Stored procedures. I tend to write stored procedures for both parameters and the report data. By using stored procedures for parameter datasets they can be easily shared between reports. For report data I like to make certain that I draw a clear line between the data within a report and the formatting that comes out. By keeping that line it has been easier in my experience to test and promote reports to production.
Also, I find stored procedures a little easier to manage and troubleshoot than a view or in-report queries.
You should not bother with in-report queries, they are pretty much there to play with and practice. But you can hardly get a very good report writing a query directly in RS. Why..well for one thing a lot of sprocs can be reused not only for the application side but also the reporting side. Your application may have various stored procedures used to fill drop down lists / combo boxes that cascade (one relates on another). You may need this functionality for your reports as well. With stored procedures you could issue a call to the sproc from your report or your application. When the sproc changes (if it ever has to), you're ok because the updates you made to the application stored procedure also update your report's stored procedures.
My vote is definately for stored procedures.
I have been working with MS Reporting Services for about one full year now. I found that the best way to generate reports with this system is to run queries from your data access layer, via stored procedures.
If find that if you do it this way, you have all your returned datasets in one spot. It makes it easier to manage. All your database output is controlled from the same location.
Off topic but I would also recommend that you generate your RDLC files in memory. We have about 100 different report types. Instead of managing a bunch of RDLC files, we manage a ReportEngine class. The ReportEngine class basically generates a bunch of different report types. This is quite advanced, but the results are worth it. Source code to generate a RDLC file with a table: C# or VB.NET.
First of all there is a partial question regarding this, but it is not exactly what I'm asking, so, bear with me and go for it.
My question is, after looking at what SubSonic does and the excellent videos from Rob Connery I need to ask: Shall we use a tool like this and do Inline queries or shall we do the queries using a call to the stored procedure?
I don't want to minimize any work from Rob (which I think it's amazing) but I just want your opinion on this cause I need to start a new project and I'm in the middle of the line; shall I use SubSonic (or other like tool, like NHibernate) or I just continue my method that is always call a stored procedure even if it's a simple as
Select this, that from myTable where myStuff = StackOverflow;
It doesn't need to be one or the other. If it's a simple query, use the SubSonic query tool. If it's more complex, use a stored procedure and load up a collection or create a dataset from the results.
See here: What are the pros and cons to keeping SQL in Stored Procs versus Code and here SubSonic and Stored Procedures
See answers here and here. I use sprocs whenever I can, except when red tape means it takes a week to make it into the database.
Stored procedures are gold when you have several applications that depend on the same database. It let's you define and maintain query logic once, rather than several places.
On the other hand, it's pretty easy for stored procedures themselves to become a big jumbled mess in the database, since most systems don't have a good method for organizing them logically. And they can be more difficult to version and track changes.
I wouldn't personally follow rigid rules. Certainly during the development stages, you want to be able to quickly change your queries so I would inline them.
Later on, I would move to stored procedures because they offer the following two advantages. I'm sure there are more but these two win me over.
1/ Stored procedures group the data and the code for manipulating/extracting that data at one point. This makes the life of your DBA a lot easier (assuming your app is sizable enough to warrant a DBA) since they can optimize based on known factors.
One of the big bugbears of a DBA is ad-hoc queries (especially by clowns who don't know what a full table scan is). DBAs prefer to have nice consistent queries that they can tune the database to.
2/ Stored procedures can contain logic which is best left in the database. I've seen stored procs in DB2/z with many dozens of lines but all the client has to code is a single line like "give me that list".
Because the logic for "that list" is stored in the database, the DBAs can modify how it's stored and extracted at will without compromising or changing the client code. This is similar to encapsulation that made object-orientd languages 'cleaner' than what came before.
I've done a mix of inline queries and stored procedures. I prefer more of the stored procedure/view approach as it gains a nice spot for you to make a change if needed. When you have inline queries you always have to go and change the code to change an inline query and then re-roll the application. You also might have the inline query in multiple places so you would have to change a lot more code than with one stored procedure.
Then again if you have to add a parameter to a stored procedure, your still changing a lot of code anyways.
Another note is how often the data changes behind the stored procedure, where I work we have third party tables that may break up into normalized tables, or a table becomes obsolete. In that case a stored procedure/view may minimize the exposure you have to that change.
I've also written a entire application without stored procedures. It had three classes and 10 pages, was not worth it at all. I think there comes a point when its overkill, or can be justified, but it also comes down to your personal opinion and preference.
Are you going to only ever access your database from that one application?
If not, then you are probably better off using stored procedures so that you can have a consistent interface to your database.
Is there any significant cost to distributing your application if you need to make a change?
If so, then you are probably better off using stored procedures which can be changed at the server and those changes won't need to be distributed.
Are you at all concerned about the security of your database?
If so, then you probably want to use stored procedures so that you don't have to grant direct access to tables to a user.
If you're writing a small application, without a wide audience, for a system that won't be used or accessed outside of your application, then inline SQL might be ok.
With Subsonic you will use inline, views and stored procedures. Subsonic makes data access easier, but you can't do everthing in a subsonic query. Though the latest version, 2.1 is getting better.
For basic CRUD operations, inline SQL will be straight forward. For more complex data needs, a view will need to be made and then you will do a Subsonic query on the view.
Stored procs are good for harder data computations and data retrieval. Set based retrieval is usually always faster then procedural processing.
Current Subsonic application uses all three options with great results.
I prefer inline sql unless the stored procedure has actual logic (variables, cursors, etc) involved. I have been using LINQ to SQL lately, and taking the generated classes and adding partial classes that have some predefined, common linq queries. I feel this makes for faster development.
Edit: I know I'm going to get downmodded for this. If you ever talk down on foreign keys or stored procedures, you will get downmodded. DBAs need job security I guess...
The advantages of stored procedure (to my mind)
The SQL is in one place
You are able to get query plans.
You can modify the database structure if necessary to improve performance
They are compiled and thus those query plans do not have to get constructed on the fly
If you use permissions - you can be sure of the queries that the application will make.
Stored procedures group the data and the code for manipulating/extracting that data at one point. This makes the life of your DBA a lot easier (assuming your app is sizable enough to warrant a DBA) since they can optimize based on known factors.
Stored procedures can contain logic which is best left in the database. I've seen stored procs in DB2/z with many dozens of lines but all the client has to code is a single line like "give me that list".
the best advantage of using stored procs i found is that when we want to change in the logic, in case of inline query we need to go to everyplace and change it and re- roll the every application but in the case of stored proc change is required only at one place.
So use inline queries when you have clear logic; otherwise prefer stored procs.