Viewing 15 posts - 51,901 through 51,915 (of 59,091 total)
Yes... for example, see the following... it solves one of the worst performance problems in SQL Server that there is... Running Totals... will do a running total on a million...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 11, 2008 at 5:59 am
You need to explain the rest... first row, even if you skip it, must have the same number and type of delimiters or the second row may cause an error...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 11, 2008 at 5:56 am
kent waldrop (3/11/2008)
OK, Jeff, but that was not what I was asking.
Thought I'd answered your question, Kent... what were you actually asking?
--Jeff Moden
Change is inevitable... Change for the better is not.
March 11, 2008 at 5:54 am
Jim Russell (3/11/2008)
Great suggestion Jeff!I don't suppose I can prefix the temp procedure name with a '#', so my "main" will need to drop it when done?
Temporary stored procedures begin...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 11, 2008 at 5:52 am
Kiran,
I recommend that you spend a couple of hours reading about indexes in Books Online (comes free with SQL Server). Start by reading "Indexes, Overview" in the index tab...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 11, 2008 at 5:49 am
Almost forgot... as of SQL Server 2005, SQL Server can also use a form of Try/Catch. I'd don't use it because I never got into "programming by exception" because...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 11, 2008 at 5:39 am
You can either raise a "success" error or have the app process the "RETURN" code, or both...
CREATE PROCEDURE sales.up_EmpDelete
@SSN CHAR(9)
AS
--=====...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 11, 2008 at 5:36 am
You need to use a BCP format file. See Books Online for how to build one... it's not that hard.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 11, 2008 at 5:19 am
Don't use either terminator in the code... the defaults are probably correct for your single column text file.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 11, 2008 at 5:16 am
Sarvesh Kumar Gupta (3/11/2008)
--Jeff Moden
Change is inevitable... Change for the better is not.
March 11, 2008 at 5:13 am
Note that it matters, but I like that vertical format better. More closely resembles even preformatted hard-copy schedules.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 11, 2008 at 5:06 am
Doesn't matter who's on what... shrinking a database should not be done just as a matter of fact either automatically or by scheduled task.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 11, 2008 at 4:58 am
Yes, that would be the safe guard... but, I recommend that you don't rely on that safeguard as a programming tool... takes a comparitively long time to have an error...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 11, 2008 at 4:52 am
It's the same mistake that many make... GOOGLE "3rd Normal Form" to find out about database "normalization" and why it's important despite the fact the you might have to join...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 11, 2008 at 4:42 am
Heh... If I remember correctly, it's called "Agile" programming... and it sucks. I no longer wait for sp1 to upgrade... now I wait for sp2.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 11, 2008 at 12:31 am
Viewing 15 posts - 51,901 through 51,915 (of 59,091 total)