Viewing 15 posts - 53,776 through 53,790 (of 59,072 total)
Sorry for my bit of sarcasm... you do realize that you get 999 ID's and that's it, don't you?
--Jeff Moden
Change is inevitable... Change for the better is not.
December 2, 2007 at 4:52 pm
I'm sorry, I don't see the pattern...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 2, 2007 at 4:49 pm
B
--Jeff Moden
Change is inevitable... Change for the better is not.
December 2, 2007 at 4:45 pm
I've done some testing and if you put an exclusive lock on a table you're deleting from and leave only the PK (doesn't matter if clustered or not), takes 15...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 2, 2007 at 7:55 am
but when you're dealing in hundreds of millions of records with finite resources you have to delete it sometime.....and when the garbage man comes around to remove the records flagged...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 1, 2007 at 5:16 pm
Hmmm... and what do you do for sprocs that are used by multiple applications?
--Jeff Moden
Change is inevitable... Change for the better is not.
December 1, 2007 at 4:04 pm
I can find a lot of stored procedures that are available
"Steal" code from those...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 1, 2007 at 9:30 am
And, I'm not so sure about the need for the cross join... but I'm on my way out for the day...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 1, 2007 at 9:27 am
Oracle is very picky about the reuse of table aliases within a given query... try this...
SELECTP.patno, P.name, P.docno, P.docname, P.specialization, COALESCE( T.NoOfTreatments, 0 ) AS NoOfTreatments
FROM(
SELECTPa.patno, Pa.name, D.docno, D.docname,...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 1, 2007 at 9:22 am
Heh... "A Developer must not guess... a Developer must KNOW"...
... especially in a political environment where you are challenging incumbent "knowledge".
One of the most difficult things you can do is...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 1, 2007 at 9:06 am
Try this instead...
--DROP TABLE dbo.FirstName,dbo.LastName
--===== Create a couple of test tables
CREATE TABLE dbo.FirstName
(
...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 30, 2007 at 8:01 pm
Thanks, Cali. I appreciate the feedback.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 30, 2007 at 7:38 pm
Just a suggestion...
If you regularly load large amounts of data using BCP or Bulk Insert, consider making a "staging area" database. Because all data in a staging area should...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 30, 2007 at 7:36 pm
Ummmm... OK... Guess I don't understand... why are you keeping any rows for a long period of time in a "staging area"... all of that data should be expendable to...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 30, 2007 at 3:35 pm
Or... you could kick off the proc and do a WAITFOR DELAY 'hh:mm:ss'.
Of course, if the server get's taken down or the job ever fails, you need to manually restart...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 30, 2007 at 2:59 pm
Viewing 15 posts - 53,776 through 53,790 (of 59,072 total)