Viewing 15 posts - 58,741 through 58,755 (of 59,091 total)
Yeah, I didn't say that quite right... BOL has a better way of saying what I so poorly said...
Each time an instance of SQL Server starts, it recovers each database,...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 25, 2005 at 8:02 pm
"I want to fetch code from each file (in Query Analyzer) and then do as you said i.e. execute the code.
But how do i loop through a dos directory in...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 25, 2005 at 7:56 pm
...or do you mean you want to execute them in a DOS batch run (ie. filename.BAT)? If you want to execute the files from there, then you would use OSQL...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 25, 2005 at 5:52 am
Here's the calculation you requested... it's quite a bit more complicated that when weekends are Sat/Sun because SQL Server's "Week" datepart always breaks between those two days. And, DateFirst has...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 24, 2005 at 9:42 pm
>is it okay to clear transaction log in mssql server ?
Yes... unless the server crashed and you need to roll some data forward.
>if it's ok, how to clear transaction...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 17, 2005 at 9:28 am
Either way, there have been problems with SP_OA and memory leaks of one form or another. My recommendation is to test it for memory leaks before you put it into production...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 9, 2005 at 11:39 pm
A version without a correlated sub-query... but only if you can guarantee that the date you use is a month end date and that all of the DateMonthEnd dates are...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 9, 2005 at 8:41 pm
I found it and I was correct...
They first found memory leaks in the SP_OA procs in SQL Server 6.5 and supposedly fixed it... see the following URL:
http://support.microsoft.com/kb/151601/EN-US
I guess...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 9, 2005 at 8:13 pm
It sounds like you may need to build a "Calendar Table". Lot's of folks have wriiten about their construction and use. I'd also recommend taking a peek at the following...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 9, 2005 at 11:27 am
Jon,
What kind of VB functionality are you looking to do?
--Jeff Moden
Change is inevitable... Change for the better is not.
July 9, 2005 at 9:18 am
IF OBJECT_ID('TempDB..#Results') IS NOT NULL
DROP TABLE #Results
SELECT IDENTITY(INT,1,1) AS RowNum,
...other columns as you need...
INTO #Results
FROM ...your tables and joins...
ORDER BY ...the order you...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 7, 2005 at 8:18 pm
You CAN get an estimated execution plan when you use temp tables by first executing just the code that makes the temp tables and then doing the execution plan. If...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 7, 2005 at 7:51 pm
Pretty sharp, Womalley... sometimes ya gotta do what ya gotta do.
--Jeff Moden
Change is inevitable... Change for the better is not.
July 7, 2005 at 7:45 pm
The use of xp_CmdShell is considered to be a security risk by most DBA's and, I believe, the default is you must have"SA" (not just "dbo" rights to use it. You...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 25, 2005 at 8:31 am
rschaeferhig,
You were quite right... you didn't change much. In fact, when I built a test Directory and Employees table and inserted the records you showed in a previous...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 7, 2005 at 10:02 pm
Viewing 15 posts - 58,741 through 58,755 (of 59,091 total)