Viewing 15 posts - 57,676 through 57,690 (of 59,101 total)
If you have a clustered index, change it to a non-clustered index. That'll help a highly transactional table a bit, as well, especially if you have a lot of inserts...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 14, 2006 at 9:46 pm
I found an alternative in XP... right click on the desktop, select [Properties], select the [Appearance] tab, and change the [Font Size] setting to LARGE or EXTRA LARGE.
--Jeff Moden
Change is inevitable... Change for the better is not.
September 14, 2006 at 9:40 pm
I'm afraid that's it... if you want to change the font "size" in EM, I believe you are going to have to change the screen resolution (right click on the...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 14, 2006 at 9:37 pm
Despite the fact that it recompiles every time it is used, I've found nothing faster than the following especially since page size and page number can be parameterized in a...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 14, 2006 at 9:26 pm
SwTrans,
I guess I don't see what your problem is or what you're actually trying to do... why wouldn't the following work for you?
DECLARE @UseIt1 as varchar(100)
DECLARE @WorkQueue AS VARCHAR(100)
SET @WorkQueue...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 14, 2006 at 9:14 pm
Sushila,
You're having one of those days like I did on the trigger thing... ![]()
DECLARE @UseIt1 as varchar(100)
EXEC ('SET ' + @UseIt1 +...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 14, 2006 at 9:03 pm
Whew! The number 6 would have really messed me up... I only have 5 fingers on each hand! ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
September 14, 2006 at 8:54 pm
Yep... and keep in mind that SELECT/INTO only works once on any given target table unless you drop the table... but that would defeat the archive, eh ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
September 14, 2006 at 8:51 pm
Lee,
You used the key words "query the dataset". Cursors contain a bunch of rows but they can only be worked on or "fetched" one agonizing row at a time. If...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 14, 2006 at 8:48 pm
Sure you do... "Old" = Parent, "New" = Child. It's a classic hierarchical problem. There has to be a dozen good articles and lot's of good posts on this forum...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 14, 2006 at 8:34 pm
I believe that what you are looking for may be solved with "dynamic SQL". There has to be a thousand good postings on this forum about it... try a search...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 14, 2006 at 8:28 pm
I've found the even Microsoft uses the "undocumented" features
Works for me!
--Jeff Moden
Change is inevitable... Change for the better is not.
September 14, 2006 at 8:24 pm
Concure with that... isn't there an autonumbering column or a date/time column or a consecutive ID column of any sort? How about a clustered primary key? There has to be something...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 14, 2006 at 8:22 pm
I've never seen it fail either (and it's been 10 years)... however, the first article says it's guaranteed to be OK if you create the table with the IDENTITY column...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 14, 2006 at 8:16 pm
Thought I'd throw my 2 cents in here because lot of folks run into some real problems when using ranges of dates as criteria...
BETWEEN is fine for date ranges......
--Jeff Moden
Change is inevitable... Change for the better is not.
September 14, 2006 at 8:07 pm
Viewing 15 posts - 57,676 through 57,690 (of 59,101 total)