Viewing 15 posts - 39,046 through 39,060 (of 59,072 total)
Paul White NZ (4/5/2010)
Technically, neither of these functions are guaranteed to never produce a duplicate
Actually, they are. From Books Online:
If an application must generate an identifier column that...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 5, 2010 at 4:04 pm
konstantinos.christodoulakis (4/5/2010)
More info:Table name: MSP_RESOURCES
EmployeeID: RES_UID (PK, UID(uniqueidentifier)
EmployeeName: RES_NAME (NAME(nvarchar(255)),not null)
EmployeeApprover: RES_TIMESHEET_MGR_UID (UID(uniqueidentifier),null)
Do I need to create a new table and select from there?
It would be much more handy if...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 5, 2010 at 3:43 pm
konstantinos.christodoulakis (4/5/2010)
It's really a recursive query, but easier that you make it:
SELECT e1.RES_UID, e1.RES_NAME, e1.RES_TIMESHEET_MGR_UID, e2.RES_NAME AS TimesheetManagerName
FROM MSP_RESOURCES e1 LEFT JOIN MSP_RESOURCES e2 ON e1.RES_TIMESHEET_MGR_UID...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 5, 2010 at 3:41 pm
COldCoffee (4/5/2010)
SELECT
EH.EmpID AS EmpID,
EH1.EmpName AS EmpName ,
EH.EmpName...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 5, 2010 at 3:40 pm
Hmmmm.... be careful, folks. I thought I recognized the pattern in the Cross Apply. It contains a Triangular Join and I just tested it on just 10K rows......
--Jeff Moden
Change is inevitable... Change for the better is not.
April 5, 2010 at 2:54 pm
As a bit of a side bar, I don't know if you're data is actually like you posted it but, just in case, I'd recommend you NOT store formatted dates...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 5, 2010 at 11:13 am
The column that contains the unique identifier datatype does not enforce uniqueness. Just like an identity column, you need to put a constraint on it in the form of...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 5, 2010 at 10:40 am
Heh... me niether... 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
April 5, 2010 at 8:03 am
Thanks, Matt... Whew!... I thought you were building an "retail" application that, once released, was going to be making changes to the structure of DB objects.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 5, 2010 at 7:13 am
The Dixie Flatline (4/4/2010)
--Jeff Moden
Change is inevitable... Change for the better is not.
April 5, 2010 at 6:55 am
david_wendelken (4/4/2010)
He didn't care if it worked on December 31st, he only cared that it could be announced to work on that date.
BWAA-HAA!!! Great true story. Unlike Paul,...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 5, 2010 at 6:39 am
Tom.Thomson (4/5/2010)
who are prepared to lie about how much testing they have done because they think they will get away with it.
Heh... I love it when they do that....
--Jeff Moden
Change is inevitable... Change for the better is not.
April 5, 2010 at 6:31 am
P.S. There are two huge discussions after articles on the problem of "FizzBuzz". Read the discussions (search for them first, obviously) and understand the difference between someone who...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 4, 2010 at 3:06 pm
Learning Oracle is a must if I want get anywhere in the industry.
I'm convinced that Larry wrote that himself. Ignore it or act on it but don't...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 4, 2010 at 3:01 pm
skjoldtc (3/19/2010)
The idea is simply to write comparative tests into the code; you have the "proven but unsupported" production method and then, at its side, a very "safe" method that...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 4, 2010 at 2:42 pm
Viewing 15 posts - 39,046 through 39,060 (of 59,072 total)