Viewing 15 posts - 57,211 through 57,225 (of 59,067 total)
I agree... there's still some info missing...
Brian, are you simply saying that you want to be able to update any row and insert new rows from the app?
Or are you...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 25, 2006 at 3:36 pm
If it's the Primary Key, then you may be (will be) destroying referential integrity for other data in other tables. If it's the Primary Key and you don't have referential integrity,...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 25, 2006 at 9:40 am
I'd never use @@Identity because it is not scope sensitive and, in the presence of triggers, will surely return an incorrect value. Always use SCOPE_IDENTITY for such a thing.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 24, 2006 at 4:55 pm
Yes, it is possible to modify the number by first doing a SET IDENTITY INSERT... here's the syntax from Books Online...
SET IDENTITY_INSERT [ database. [ owner. ] ] { table...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 24, 2006 at 4:53 pm
Actually, there is one method that's a few milliseconds faster over a million or so rows...
SELECT CAST(CAST(datecolumn-.5) AS INT) AS DATETIME)
As usual, please don't take my word for...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 24, 2006 at 4:48 pm
Felix...
You may want to post some of those custom functions you're talking about... you'd be surprised at how some of them can be speeded up or maybe even eliminated with...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 24, 2006 at 4:33 pm
And, you still need to determine.... is null a date way back in the past or a date in the future?
--Jeff Moden
Change is inevitable... Change for the better is not.
November 24, 2006 at 4:27 pm
The destination table has a ROWID field which cannot be an identity key, ...
Why the heck not?
--Jeff Moden
Change is inevitable... Change for the better is not.
November 24, 2006 at 4:22 pm
I'm not seeing the pattern here... can you explain how you came to the actions you took and why you need to do the INSERT to begin with? What do...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 24, 2006 at 4:17 pm
Yes, there are some concerns...
SQL Injection Attacks
Poor performing code due to recompiles because is really 100% dynamic SQL
Poor performing code because it's written by GUI experts who might not be...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 24, 2006 at 4:11 pm
Thanks for taking the time to provide the belated feedback
Lot's of times, you wonder if someone died or what? 
--Jeff Moden
Change is inevitable... Change for the better is not.
November 24, 2006 at 4:02 pm
This would work...
SELECT *
FROM dbo.PostalCodes P WITH (NOLOCK)
WHERE SQRT(
POWER((69.1 * (P.Latitude - @Lat1)),2.000)
+ POWER((53 * (P.Longitude - @Long1)),2.000)
) <= @Distance
...but I believe this only works...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 20, 2006 at 9:42 pm
Cool... thanks for the feedback, Mick.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 17, 2006 at 8:12 am
"SysDate"
"Months_Between"
Are you trying to do this in Oracle or SQL Server?
--Jeff Moden
Change is inevitable... Change for the better is not.
November 16, 2006 at 8:53 pm
DTS the production tables to a development database.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 16, 2006 at 8:48 pm
Viewing 15 posts - 57,211 through 57,225 (of 59,067 total)