Viewing 15 posts - 22,516 through 22,530 (of 59,099 total)
klineandking (11/11/2014)
i have asked the question,assume both tables are a heap,how would you update the table in batches of 5000
Unless there's an index on the EncryptionID of both tables, the...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 11, 2014 at 8:46 am
Never mind. I believe the following does what you ask. You'll need to change the table name in the FROM clause to whatever your tablename actually is. ...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 10, 2014 at 8:34 pm
tamer.h (11/10/2014)
here is a table shows the dates and times of entry and exit of staff throughout the day, where each record shows that either employee's entry...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 10, 2014 at 5:37 pm
What this whole thing looks like is the possibility of SQL Injection. It also looks like a "Catch All" query and the proper way to do it can be...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 10, 2014 at 5:13 pm
Caching is a good idea but with only 10,000 rows, this should be sub-second. The correct indexes will make that happen.
Shifting gears a bit, if you really...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 10, 2014 at 3:56 pm
thottle (11/10/2014)
Are you absolutely sure that something other than WidgetA and WidgetB have data for the last 7 days?
Yes. If it doesn't, dataset 2 tossed up a blank report,...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 10, 2014 at 3:04 pm
chandrachamarthi8 (11/10/2014)
it display the schema on the result
Look carefully. Are you sure that it shouldn't be spelled "customer" instead of "coustmer"?
--Jeff Moden
Change is inevitable... Change for the better is not.
November 10, 2014 at 2:59 pm
thottle (11/10/2014)
I wrote a report that pulls datasets from two different SPROCs.
Dataset 1 has the following code (sanitized to protect the...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 10, 2014 at 2:43 pm
mhildebrand (11/10/2014)
--Jeff Moden
Change is inevitable... Change for the better is not.
November 10, 2014 at 2:37 pm
Do you have the correct indexes on the table to support the hierarical lookups caused by the recurssion of the CTE? Also, who is going to read 10,000 rows?
--Jeff Moden
Change is inevitable... Change for the better is not.
November 10, 2014 at 9:34 am
If it's supposed to be based on ISO week number, substitute the ISOWEEK datepart in Sean's good code above.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 10, 2014 at 7:40 am
haichells (11/10/2014)
I have a 2008 database where I take Full backup on Saturday and Log backup (once in a day) for rest of the days. Here my log backup files...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 10, 2014 at 7:34 am
Steve, I have an idea. Set it up so that when I report a post as spam and I include a secret word in the report, have the system...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 9, 2014 at 7:06 pm
There's one other difference depending on how it's coded. Performance. RBAR inserts tend to be incredibly slow compare to multi-row set-based inputs.
Which brings me to a subject...
Lot's of...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 8, 2014 at 8:16 pm
Would [font="Courier New"]WHERE somecolumn <> 0[/font] do it for you?
--Jeff Moden
Change is inevitable... Change for the better is not.
November 7, 2014 at 10:06 pm
Viewing 15 posts - 22,516 through 22,530 (of 59,099 total)