Viewing 15 posts - 56,626 through 56,640 (of 59,069 total)
Halifaxdal...
I just noticed that the size of the MDF table doubled when you added the column... you've done something wrong... very wrong... stop modifying the original table!!!
--Jeff Moden
Change is inevitable... Change for the better is not.
April 6, 2007 at 5:19 pm
Heh... point well taken, David... we have a day or two just like that. Our "big one" is affectionately known as "Cycle 28".
--Jeff Moden
Change is inevitable... Change for the better is not.
April 6, 2007 at 4:59 pm
Sorry Andreas... That's absolutely incorrect and you really need to check your facts before making such an unqualified statement... Try this... insert a column in the middle of an existing...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 6, 2007 at 4:51 pm
You are partially correct... all of the SQL objects will be constructed from what is in the MODEL... However, the listing from sysfiles shows the following file names for the...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 6, 2007 at 4:02 pm
Heh... I missed THAT! Not only does the table need some fixin', but you do need to add some memory! My desktop box has a gig... a server running standard...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 6, 2007 at 8:06 am
Cory,
Great idea but, the Model DB files don't show where new files would be made (as a default)... they only show where the current Model files are.
For the other DB's, then sysfiles...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 6, 2007 at 7:59 am
KBrown,
You all set? Michael's solution seems to do what you asked but just making sure (pretty cool sequence generation function he's got there, huh?) because of the duplication of stock...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 6, 2007 at 7:29 am
You DO need to access the registry... You can either do it from the front end or you can read them using the unsupported xp_RegRead stored procedure. For SQL Server...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 6, 2007 at 6:44 am
Yardstick? Is that anything like the 2x4 I normally use? ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
April 5, 2007 at 9:57 pm
Oh yeah... almost forgot... you need a complete list and script for any triggers that may exist on the table as well as a complete list of views that use...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 5, 2007 at 9:53 pm
Ok, I can tell you're just a little nervous about this whole thing and I don't blame you one little bit... so, here's the plan and why I asked the...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 5, 2007 at 9:16 pm
Nope... I've seen this before... I call it "chain" join. If we look at Wade's join "chain"...
FROM Inventory AS I
JOIN Block AS B
JOIN Phase AS P
JOIN ProjectSub AS PS
JOIN...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 5, 2007 at 6:19 pm
Only way that could happen is if group_sec doesn't exist... what do you get when you run the following?
SELECT COUNT(Group_Sec) FROM TestTable
--Jeff Moden
Change is inevitable... Change for the better is not.
April 5, 2007 at 5:25 pm
They do the same thing where I work and it drives me nuts... what's the purpose of an archive? Right... to move infrequently used data out of the way for...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 5, 2007 at 5:09 pm
Using a cursor to do a simple "UPSERT"?? You an Oracle programmer, Simon? ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
April 5, 2007 at 5:03 pm
Viewing 15 posts - 56,626 through 56,640 (of 59,069 total)