Viewing 15 posts - 49,741 through 49,755 (of 59,099 total)
Paul McKay (5/21/2008)
I'll stick up some data for this tomorrow following Jeff's guidelines if I can.
Is it tomorrow yet? 😉
Just teasing... did you ever get this figured out, Paul?
--Jeff Moden
Change is inevitable... Change for the better is not.
June 24, 2008 at 7:19 pm
David O (5/7/2008)
I just spent an afternoon re-writing a proc that should have been easy to write but instead I get a piece of crap that kills my server.
You...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 24, 2008 at 7:15 pm
The code you have posted is not meant to be executed by you... things like sp_cursoropen are SQL Server code that appears when SQL Server actually runs a stored proc.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 24, 2008 at 6:51 pm
This old trick using a Tally table may help... I did not modify it to match your tables... see the link in my signature if you want that 😉
--===== This...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 24, 2008 at 6:46 pm
I don't know of a direct method... but can you have MySQL export to either a Tab Delimited or CSV file? From there, it's easy to import into SQL...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 24, 2008 at 6:43 pm
Constraints are meant to protect the data.... little things like Primary Keys and Foreign keys as well as some data level constraints in columns keep people from entering garbage into...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 24, 2008 at 6:37 pm
Ummm... you're probably not getting any answers because there's not really enough data for folks to go on.... and a lot of them (me included) want to see some other...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 24, 2008 at 6:33 pm
If you can run it, then the job needs the same privs as you.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 24, 2008 at 6:01 pm
Sorry Mike, I've never used either. Hopefully, someone that has will see this...
...yeah... I'm "bumping" Mike's post because he didn't get an answer and I'm curious as well... 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
June 24, 2008 at 5:59 pm
No need for a cursor or While loop here... makes the code too long and slow. Try this instead...
--===== This makes a little test table according to the post
...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 24, 2008 at 5:57 pm
The major point has been missed... Andras explained it. You need a date column or an IDENTITY column to figure out what the last row actually is. Adding...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 24, 2008 at 5:15 pm
I find the co-existence of various ways of doing the same thing maddening
I find it makes sex interesting :w00t: Oops... sorry... wrong forum 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
June 24, 2008 at 5:11 pm
I think the only thing concrete is what the minimum installation requirements/recommendations are and what the maximum is. The rest is up to you to figure out based on...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 24, 2008 at 5:04 pm
Just in case you don't know... you can combine the two in a single select...
SELECT MIN(ValidateFromDate) AS MinDate,
MAX(ValidateFromDate) AS MaxDate
...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 24, 2008 at 4:53 pm
If you try to join 32 tables with multiple aggregates and functions on columns in the ON or WHERE clauses, it'll likely be better to use "Divide'n'Conquer" methods in a...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 24, 2008 at 4:43 pm
Viewing 15 posts - 49,741 through 49,755 (of 59,099 total)