I have a method that takes a SQL query and a file name, then converts that query into an XML-based Excel file. Works great. The code gets the schema of the query, and uses the column names to generate the column headers in Excel. This, too, works great.
The problem is aliasing the columns into the headers that I want. I am using this notation:
Whether I have one column or 50, the query takes several minutes to run; the more data, the longer it takes. If I were to use SELECT *, with no aliasing, I can return the data in a few seconds, regardless of how many rows are returned.
I have also tried view.MeaninglessColumnNameImposedBySystem1 AS [First Name], which does not speed up the results.
Presumably, this is an optimization issue where * lets SQL make assumptions that it cannot when each column is aliased. Any suggestions on what I can do with the query to speed things up?
SELECT V.MeaninglessColumnNameImposedBySystem1 [First Name],
V.MeaninglessColumnNameImposedBySystem2 [Last Name],
V.MeaninglessColumnNameImposedBySystem3 [Address 1],
FROM LongViewName AS V
for best practice go for Column names without any space like FirstName, LastName, Address1 ...
I am trying to avoid that: the idea is to have one general method that will take any of nine queries to generate different files than to have nine specialist methods that each take only a single query.
Somewhere you are defining the column names (you want it done on the entry query definition) either in 1 or 9 query constructors, I am suggesting moving the naming to post query execution, sticking that code into 1 method is trivial. Still it is a kludge b/c the aliasing should work
Never underestimate the power of human stupidity
Like I said, the aliasing is working, but it takes a very long time for the query to return. In one test case, a query with aliased columns took almost 6 minutes to return; the identical query with unaliased columns took less than a second. This kind of time difference is pretty consistent, regardless of how many columns are requested, and scales closely to the number of rows returned (the more rows, the longer the aliased query takes.)
I traced the problem to a piece of code that uses SqlDataAdapter.Fill to populate a DataSet, then took to the Internet.
It turns out that there is some optimization that SQL does with queries, where it tries to import indexes from underlying tables. This works fine as long as the columns in the view match up with the columns from the tables. When you alias the query's columns, however, things can degenerate into a quagmire of competing indexes; the delay is caused by SQL trying to wait out a resolution. You can get rid of the delay by instructing SQL to abandon arithmetic operations that result in an overflow or underflow. Huh?
The solution was to prefix the query with SET ARITHABORT ON; which tells SQL to just fly over the swamp rather than try to navigate through it. After the query, tack on ; SET ARITHABORT OFF; to reset the server variable, mainly because there is probably a reason why it set to OFF in the first place.
Please can you tell me what is the best tool for creating a database from scratch?
If that wasn't the answer you thought you were looking for then you need to understand that you don't choose a database based on tool but rather on the functionality of the database vendor. AFTER you have chosen a database then you look for applications that allow you to manage the database application.
It's all about learning not working! so I want to know the tool which can help me to insert data and retrieve it and more.
is SQL server the tool that can help me? or ADO.NET?? and what is the difference between them??
Just Like Mark wrote, I start with the whiteboard.
When that gets to small I make the model in Oracle SQL Developer Data Modeler [^], which supports Oracle, SQL Server and DB2 out of the box, and you can make your own design rules as well.
And as an extra plus, it supports source control via Subversion.
"The ones who care enough to do it right care too much to compromise."
If its running for 3 days, then for the first day it executes perfectly.
For the second day and remaining all days it gives following error.
Strange. Based on what you share, sounds like some logical error where you are considering the DayNo. Are you? Somehow, somewhere the current day is getting into picture while running the procedure and the error. Did you DEBUG and see? Check if so.
A primary key (often) consists out of multiple columns. I'd suggest putting the primary key on BOTH, and to add an autoincrement-field and make that unique. Use the autoincrement-column to make relations to other tables.