Viewing 15 posts - 45,766 through 45,780 (of 59,101 total)
This problem occuring in only one table and situation occurs with only records already existed in the database.
How do you know the records already existed in the database? And,...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 19, 2009 at 7:43 pm
sal527 (1/19/2009)
Thanks to all, the issue has resolved and i am sorry as i could not reply at the same time.
Two way street here, chum... would you mind telling...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 19, 2009 at 7:40 pm
This is absolutely the wrong thing to do. Dates should not be stored as integers.
What are the business rules stating that you should convert the column from a DATETIME...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 19, 2009 at 7:36 pm
Perhaps pre-aggregated and dynamic crosstabs would help a bit...
http://www.sqlservercentral.com/articles/T-SQL/63681/
http://www.sqlservercentral.com/articles/cross+tab/65048/
I've had a lot of success with the combination.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 19, 2009 at 7:31 pm
If someone else is doing the same thing and are in the process of modifying data, there may be an open transaction that is locking the table and no timeout...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 19, 2009 at 7:27 pm
Aren't there about 10 million articles on how to break pwdencrypt() ?
--Jeff Moden
Change is inevitable... Change for the better is not.
January 19, 2009 at 7:23 pm
No need for a variable, at all...
SELECT SiteName
FROM db2.dbo.Customer c2
INNER JOIN db1.dbo.Site s1
ON c2.SiteName = s1.Debnr
WHERE s1.Name...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 19, 2009 at 7:22 pm
All of that information is available in Books Online, as well.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 19, 2009 at 7:15 pm
SET XACT_ABORT ON
--Jeff Moden
Change is inevitable... Change for the better is not.
January 19, 2009 at 7:14 pm
I'll also add that unless your database has been set to be case sensitive, then you don't need the extra overhead of all the UPPER() functions...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 19, 2009 at 7:10 pm
Not sure it's appropriate for all of this, but if you mearly add columns to a table and the view doesn't need to be changed because it doesn't use the...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 19, 2009 at 7:05 pm
Yes... create a format file. \" is the escape character for a single quote in the delimiter column. First character in the datafile must have a length of 1...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 19, 2009 at 6:39 pm
Tim.Wilson-Brown (1/19/2009)
Is there any reason why you used NVARCHAR(128) rather than SYSNAME?SYSNAME would make the script more portable between versions - and enforce restrictions on content.
I agree that SYSNAME would...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 19, 2009 at 6:36 pm
Karthikeyan.Ponniah (1/19/2009)
--Jeff Moden
Change is inevitable... Change for the better is not.
January 19, 2009 at 6:26 pm
Sorry... you can't have "control of flow" statements like "IF" in a view.
It could, however, be easily accomplished in a stored procedure and then you could use the result of...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 19, 2009 at 6:20 pm
Viewing 15 posts - 45,766 through 45,780 (of 59,101 total)