Viewing 15 posts - 45,751 through 45,765 (of 59,095 total)
tevers (1/19/2009)
--Jeff Moden
Change is inevitable... Change for the better is not.
January 20, 2009 at 5:42 am
Larry Mitchell (12/27/2007)
The part that's throwing me off is the other dbs are working fine. The process that hits those databases is using the...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 20, 2009 at 5:36 am
jacowess,
Look at my previous post and look at your original post. If that's what you're actually running, you have syntax errors in the code.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 20, 2009 at 5:34 am
Jacob Luebbers (1/19/2009)
Jeff Moden (1/19/2009)
--Jeff Moden
Change is inevitable... Change for the better is not.
January 20, 2009 at 5:23 am
munishprathap (1/19/2009)
according to my requirement i need to keep the one column type as bigint but unfortunately
i keep it as DateTime after long time i found that it was...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 20, 2009 at 5:19 am
Well... does it?
--Jeff Moden
Change is inevitable... Change for the better is not.
January 19, 2009 at 8:32 pm
smunson (1/19/2009)
After 30 years of having to find ways to get data in or out of computer systems for almost every conceivable purpose, what I've found is that in every...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 19, 2009 at 8:30 pm
mohinidba (1/18/2009)
can not open the following files
t;\michrosoftsqlserve\mssql.1\mssql\data
all of the data files of the system dbs and user dbs.
and the...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 19, 2009 at 7:54 pm
Ummm... what happens when you run just the SELECT?
select NonEmpty [Tests].[Fixed] on columns,
from Cube
where ([Test Date].[Date].&[2009-01-16T00:00:00]
I'm thinking that you have some illegal text in the where clause and you're missing...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 19, 2009 at 7:46 pm
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
Viewing 15 posts - 45,751 through 45,765 (of 59,095 total)