Viewing 15 posts - 51,571 through 51,585 (of 59,091 total)
With the information provided, all I can say is did you remember to hit the "Run SQL Faster"? 😀
Seriously, though... we need a bit more information. First, 30,000 rows...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 22, 2008 at 9:36 am
Yan Gao (1/9/2008)
Jeff Moden (1/4/2008)
How did it help? What was the problem?I had the file open. Once I closed it, it imported fine...:)
Heh... I had the same problem...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 21, 2008 at 5:54 pm
Ah... I see... No big difference there... Use IF on SQL Server... just like you can in Oracle in this "case" 😀
It sounds like you're worried a bit about...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 21, 2008 at 9:46 am
Regardless of what the cause of the deadlock is, I guarantee it's going to be code that has a BEGIN TRAN/COMMIT in it... unless someone went nuts using that everywhere,...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 21, 2008 at 9:41 am
Utsab Chattopadhyay (3/20/2008)
Many thanks in...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 21, 2008 at 9:36 am
Sure... understood... but you want to create an auto-increment column, as well as creating a table. That's not the same between RDBMS's... for example, Oracle doesn't even allow for...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 21, 2008 at 9:18 am
Thanks for the feedback, Selena... I've made the same mistake many a time. 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
March 21, 2008 at 9:00 am
"The difficult can be done immediately, the impossible takes a little longer." — Army Corp. of Engineers
--Jeff Moden
Change is inevitable... Change for the better is not.
March 20, 2008 at 9:21 pm
Sure... go to the same source you found the info for the undocumented sp_MSForEachTable and find sp_MSForEachDB.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 20, 2008 at 8:34 pm
Just a programming note... the method that Matt used is a lot faster than recursive CTE's like the one you have over the long haul...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 20, 2008 at 8:32 pm
Thanks for sharing... but your CTE has an error in it... it won't return all of the days of March... it misses the last day because you of the <...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 20, 2008 at 8:30 pm
This is an SQL Server forum... and SQL is not SQL between RDBMS's... if you want MySQL help, I suggest you find a MySQL forum or refer to the documentation...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 20, 2008 at 8:20 pm
A "UniqueIdentifier" datatype and a default of NEWID() would probably fit the bill (although, I don't care for them. Lookup both items in Books Online for more details.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 20, 2008 at 8:18 pm
That would have been a good one to ask for some data on... 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
March 20, 2008 at 8:15 pm
For what? Got an example of the PL/SQL that you're talking about?
--Jeff Moden
Change is inevitable... Change for the better is not.
March 20, 2008 at 8:04 pm
Viewing 15 posts - 51,571 through 51,585 (of 59,091 total)