Viewing 15 posts - 51,901 through 51,915 (of 59,098 total)
No, not really... only time I do it is if someone made an accidental cross join (for example) that caused a db to become over inflated. But when that...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 11, 2008 at 7:20 am
Definitely not a trivial topic... and I haven't really found a good "starter" book on database design except for maybe some of the topics in Books Online. Before you...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 11, 2008 at 6:57 am
it isn't my problem anymore even though it bothers me that I know I could make improvements to the process (Aside, is it wrong to feel that way?) today.
No... not...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 11, 2008 at 6:45 am
Thanks for the feedback, GoodGuy... but it's all the same... just bigger, that's all 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
March 11, 2008 at 6:28 am
kent waldrop (3/11/2008)
--Jeff Moden
Change is inevitable... Change for the better is not.
March 11, 2008 at 6:24 am
Heh... yeah... they break the hell out of the 4k barrier of sp_ExecuteSQL and will return return codes just like the real ones. Neat thing is, if you need...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 11, 2008 at 6:19 am
So, tell us what the trick is...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 11, 2008 at 6:02 am
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
Viewing 15 posts - 51,901 through 51,915 (of 59,098 total)