November 26, 2009 at 6:35 pm
MarkusB (11/26/2009)
Strictly speaking you can create a job in SQL 2005 Express as well. All the necessary stored procedures in the msdb are there and you can execute them succesfully. You cannot execute them on a schedule because there's no SQL Agent, but a job exists.Just try this:
USE msdb ;
GO
EXEC dbo.sp_add_job
@job_name = N'Daily Backup' ;
GO
select * from sysjobs
GO
Exec dbo.sp_delete_job @job_name = N'Daily Backup' ;
I think the question should be in which version can you execute jobs on a schedule.
I would have to agree with this. The question in this scenario just does not quite seem to match properly. The question asks what editions can you create a job in SQL Server, far different from being able to schedule a job.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
November 27, 2009 at 5:54 am
I think this is one for Steve (Jones):
There have been a number of QoDs lately that appear to be designed deliberately to mislead, on the pretext that everyone will get it wrong and "learn from the experience". Trouble is, it just makes people cynical about QoD in general and stop them even trying to answer, because answering correctly isn't based on skill or knowledge, rather it is a simple but annoying game of chance.
November 27, 2009 at 7:00 am
dawryn (11/26/2009)
Another QoD turned sourAnd it will be covered with educational purposes :Whistling:
Hey, but at least we learned something, right?
Oh, wait...
--------
[font="Tahoma"]I love deadlines. I like the whooshing sound they make as they fly by. -Douglas Adams[/font]
November 27, 2009 at 9:07 am
Well, I can't defend this one. I have to agree, what good is it to create the job if you can't run it?
November 27, 2009 at 9:43 am
I don't think I learned anything useful by getting this question wrong. Who cares if you can create a job in express if it can't be used?
November 27, 2009 at 5:48 pm
Hopefully no one is "running" their database maintenance with these jobs on SQL 2005 and 2008 Express :-). This question smelled tricky from inception, and I am a little disappointed in myself for falling in the trap.
Not much learned here, but at least I refreshed my knowledge of SQL Server 2000 - SQL Server Agent.
November 29, 2009 at 10:47 am
I had to laugh at the LOLCats spelling of Enterprise as Enterprize! Too bad the question wasn't written in LOLCats as well... "I can haz SQL j0bz in which edishunz?":-D
November 30, 2009 at 2:57 am
kevin.l.williams (11/27/2009)
I don't think I learned anything useful by getting this question wrong. Who cares if you can create a job in express if it can't be used?
It wouldn't be difficult to write a stored proc to run at startup and thereafter every minute, which kicks the jobs off when scheduled...
November 30, 2009 at 3:00 am
david.wright-948385 (11/30/2009)
kevin.l.williams (11/27/2009)
I don't think I learned anything useful by getting this question wrong. Who cares if you can create a job in express if it can't be used?It wouldn't be difficult to write a stored proc to run at startup and thereafter every minute, which kicks the jobs off when scheduled...
Could even add "catch-up" logic to run jobs missed while the instance was down 🙂
November 30, 2009 at 8:03 am
I would imagine you could even conceive of creating these jobs and then kicking them off on a schedule based on Reporting Services Scheduled Reports, or using the windows task scheduler and an OSQL command or a variety of other resources.
There are a variety of frameworks and applications on codeplex and CodeProject amoung others to get around these same issues...
This is just the first one from Google...
December 1, 2009 at 9:10 am
Crud, I missed it. This is good to know if you have automated maintenance or admin scripts though. I guess if your scripts set up jobs on new servers, the scripts will run successfully on express, but the jobs will never start... and you'll never know that the instance isn't configured like you thought.
Chad
December 9, 2009 at 10:25 am
(deleted post about "Enterprize" haha-how-funny-but-made-me-answer-wrong and going back to work instead of playing guessing games :-P)
However I want to mention that I prefer to use *.SQL scripts with sqlcmd.exe in Windows Scheduled Tasks to do regular maintenance work and Backups instead of SQL Agent Jobs...
They are independent of SQL Editions and can be maintained without the sluggish Management Studio...
And last but not least they are much easier to deploy on multiple servers without the hassle of dealing with "Maintenance Plan" SSIS Packages and the related issues
January 30, 2010 at 12:03 pm
In SQL Server 2008, SSMSE does not support scheduling administrative tasks by using SQL Server Agent (http://msdn.microsoft.com/en-us/library/ms365247.aspx). So in effect there is no support for jobs - they can't be scheduled to run, although obviously you can create jobs using the MSDB stored procs.
In SQL Server 2005 Express Edition, jobs can be created using the MSDB stored procs just as in SQL Server 2008 Express Edition, and they can't be scheduled to run. The support for jobs is exactly as extensive or restrictive in 2008 express as it is in 2005 express, so why does the answer claim you can create them in one but not in the other?
The URL given as explanation is completely useless, it doesn't refer to jobs at all. Also, it doesn't say anything at all about SQL Server 2008, althoough the question (and the answer) both explicitly refer to 2008 as well as to 2005 and the answer makes a claim about them being different in respect to jobs in express edition.
The question and answer are thoroughly misleading, and the reference given for the explanation is completely irrelevant. This doesn't help anyone learn anything, and may even mislead someone into using the wrong edition of SQL Server 2008.
As an earlier commenter said, this sort of thing brings QOTD into disrepute.
Tom
Viewing 13 posts - 16 through 27 (of 27 total)
You must be logged in to reply to this topic. Login to reply