Viewing 15 posts - 56,896 through 56,910 (of 59,101 total)
Yep... I missed that... thanks Michael...
Jeremy, you need to change your function to a scalar function that returns a DATETIME instead of a table... then it should work ok...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 27, 2007 at 5:33 am
Personnally, the look and feel of SSC are both the best on the web I've seen. I'd leave it alone so far as any look and feel goes...
But I would...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 26, 2007 at 8:25 pm
Don't need the WorkCalendar join anymore... you have the function...
SELECT o.Order_Num,
o.CustomerNumber,
o.ItemNum,
o.RequireDate,
o.State,
tt.PrepTime,
dbo.CalcDate(o.RequireDate,-tt.PrepTime) AS RequiredShipDate
FROM dbo.Order...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 26, 2007 at 7:59 pm
I'd have to say "No". The default for this setting is "OFF". The only risk is if there's some really poor code written for GUI's that doesn't ID the type...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 26, 2007 at 7:40 pm
>>Bulk insert data conversion error (truncation) for row 10001
That error has nothing to do with the batch size... it has everything to do with the column size of your target...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 26, 2007 at 7:29 pm
Oh no, no, no... not true... check Books Online... every single example where a join is involved has the target of the update in the FROM clause, as well. In...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 26, 2007 at 7:23 pm
Like I said... make a function using the SELECT examples I gave... then just do a joined select and use the function passing the date from one table...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 26, 2007 at 7:08 pm
Mike C,
Man, nice job. I absolutely agree with Tim's assesment of the "AA" he speaks of. The real fact is "NULLs Happen"
...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 26, 2007 at 8:28 am
Speaking of "no clue"...
select(field1) + sum(field2) from #table1
... will yield ...
Server: Msg 8118, Level 16, State 1, Line 1
Column '#table1.field1' is invalid in the select...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 26, 2007 at 8:19 am
I just love the fact that there's an average of more than 16 bytes of structure for every byte of actual data
It's...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 26, 2007 at 12:16 am
Lot's of folks will do a calculation like this...
--===== A way without the WorkDayCountColumn
SELECT c.Date
FROM #Calendar c
WHERE
c.IsWorkDay = 1
AND 4+1...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 25, 2007 at 11:19 am
I see you're online right now, Jeremy... gimme a couple minutes more and I'll show you one way to do this...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 25, 2007 at 10:49 am
| I want to avoid temp tables..trying to get in a simple select if possible from system functions. |
Can you...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 23, 2007 at 10:41 pm
So, basically, it's a data model change with a cleanup script to boot and not a permanent stored procedure?
If that's true, then just add a GO on a separate line...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 21, 2007 at 5:21 pm
Thanks, SW...
Peter is correct, though... if all of the values for a given account number are <= 0, the account won't print (dunno if you want that or not). Peter's...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 21, 2007 at 5:10 pm
Viewing 15 posts - 56,896 through 56,910 (of 59,101 total)