Delete Database Maintenance Plan

If I delete the database maintenance plan, will the jobs
(Like DB Backup Job) be deleted automatically ?
Thank you for your advice.Yes! Just try it out to confirm.
--
Linchi Shea
linchi_shea@.NOSPAMml.com
"Roger Lee" <anonymous@.discussions.microsoft.com> wrote in message
news:055f01c39cfa$ce8b0440$a501280a@.phx.gbl...
> If I delete the database maintenance plan, will the jobs
> (Like DB Backup Job) be deleted automatically ?
> Thank you for your advice.

Define Job using SQL DMO

Hi Friends,
I have to define a new job, to take the backup automatically, at the SQL
Server 2000. on the Local Network if i login using the Machine name (Only
Default instance is installed), it works fine. But in the following scenario
s
it does not work -
-- If i login using IP Address of the machine on the local network.
-- If the Server is on other network on the internet.
I get the Folloing error-
[Microsoft][ODBC SQL Server Driver][SQL Server]The specified @.server_name
('192.168.100.19') does not exist.
With Thanks and Regards,
LalitHi Lalit,
Can you be more specific in what situation you see the failure? Is it when
creating the job? Can you share the script with us then (of course, strip
out any confidential info)?
Regards,
Ciprian Gerea
SDE, SqlServer
This posting is provided "AS IS" with no warranties, and confers no rights.
"Lalit" <Lalit@.discussions.microsoft.com> wrote in message
news:12AA128D-0919-457D-95E9-86FA861372CA@.microsoft.com...
> Hi Friends,
> I have to define a new job, to take the backup automatically, at the SQL
> Server 2000. on the Local Network if i login using the Machine name (Only
> Default instance is installed), it works fine. But in the following
> scenarios
> it does not work -
> -- If i login using IP Address of the machine on the local network.
> -- If the Server is on other network on the internet.
> I get the Folloing error-
> [Microsoft][ODBC SQL Server Driver][SQL Server]The specified @.server_name
> ('192.168.100.19') does not exist.
> With Thanks and Regards,
> Lalit
>|||Hi Ciprian,
Thanks for your reply.
I am doing the following
'Adding Schedule to Job
objJob.BeginAlter 'Begin changes to the job object
objJob.RemoveAllJobSchedules
objJob.RemoveAllJobSteps
'Setting JobSchedule Name
objJobSchedule.Name = "strJobName" & "_Schedule"
'Properties of Schedule
objJobSchedule.Schedule.FrequencyType = SQLDMOFreq_Daily
objJobSchedule.Schedule.FrequencyInterval = Val(txtDays.Text)
'Set Active Start date
strStartYear = DatePart("yyyy", Now)
strStartMonth = Format(DatePart("m", Now), "00")
strStartDay = Format(DatePart("d", Now), "00")
objJobSchedule.Schedule.ActiveStartDate = strStartYear & strStartMonth &
strStartDay
objJobSchedule.Schedule.ActiveStartTimeOfDay = intTime
objJobSchedule.Schedule.ActiveEndDate = SQLDMO_NOENDDATE
objJob.JobSchedules.Add objJobSchedule
objJob.JobSchedules.Refresh
objjobStep.Name = "Take_DataBackup"
'Setting Properties of JobStep
objjobStep.DatabaseName = cboDatabaseName.Text
objjobStep.Server = cboBackupServer.Text
objjobStep.Command = "DatabaseBackup"
objjobStep.OnSuccessAction = SQLDMOJobStepAction_QuitWithSuccess
objjobStep.OnFailAction = SQLDMOJobStepAction_QuitWithFailure
'Adding JobSteps to Job object
objJob.AddStepToJob objjobStep
'Commit changes to the job object
objJob.DoAlter
'Target the server to enable the job
objJob.ApplyToTargetServer "192.168.100.19"
objJob.Refresh
I Get the erro in the ApplyToTargetServer method when i am using IP address.
Where 192.168.100.19 is the IP address of the DB Server where i am connecte
d.
But the Error Message Says
[Microsoft][ODBC SQL Server Driver][SQL Server]The specified @.server_name
('192.168.100.19') does not exist
If i am providing the name of the machine then no error occurs.
With regadrs,
Lalit

default result set semantics

When an ADO command does not exhaust the default result set and a second
command is executed, the sqloledb provider automatically spawns a new session
to execute the second command (using the default result set). My question is
since command2 was definied on the connection (and prepared = true), should
one be allowed to rebind a paramter on command2 and execute again? Doing so
results in the following error -
"Multiple-step OLD DB operator generated errors. Check each OLE DB status
value, if available. No work was done."
pseudo code example:
cmd1.execute
while not rs1.eof
obtain row value, bind into cmd2
cmd2.execute
First execute works, second iteration fails.
The solution is to shutdown cmd2 within the loop and recreate the command
for each execution.
Is this the expected behavior because of the inconsistent state for the
command (having been spawned to a new session)?
I know 2005 solves this issues w/ MARS.
Thanks.
Correct. MARS in yukon is designed to solve this.
http://msdn.microsoft.com/library/en...asp?frame=true
-oj
"Thomas Brown" <ThomasBrown@.discussions.microsoft.com> wrote in message
news:B495E631-3D88-4880-B678-6E7F6DF9749C@.microsoft.com...
> When an ADO command does not exhaust the default result set and a second
> command is executed, the sqloledb provider automatically spawns a new
> session
> to execute the second command (using the default result set). My question
> is
> since command2 was definied on the connection (and prepared = true),
> should
> one be allowed to rebind a paramter on command2 and execute again? Doing
> so
> results in the following error -
> "Multiple-step OLD DB operator generated errors. Check each OLE DB status
> value, if available. No work was done."
> pseudo code example:
> cmd1.execute
> while not rs1.eof
> obtain row value, bind into cmd2
> cmd2.execute
> First execute works, second iteration fails.
> The solution is to shutdown cmd2 within the loop and recreate the command
> for each execution.
> Is this the expected behavior because of the inconsistent state for the
> command (having been spawned to a new session)?
> I know 2005 solves this issues w/ MARS.
> Thanks.
>

default result set semantics

When an ADO command does not exhaust the default result set and a second
command is executed, the sqloledb provider automatically spawns a new session
to execute the second command (using the default result set). My question is
since command2 was definied on the connection (and prepared = true), should
one be allowed to rebind a paramter on command2 and execute again? Doing so
results in the following error -
"Multiple-step OLD DB operator generated errors. Check each OLE DB status
value, if available. No work was done."
pseudo code example:
cmd1.execute
while not rs1.eof
obtain row value, bind into cmd2
cmd2.execute
First execute works, second iteration fails.
The solution is to shutdown cmd2 within the loop and recreate the command
for each execution.
Is this the expected behavior because of the inconsistent state for the
command (having been spawned to a new session)?
I know 2005 solves this issues w/ MARS.
Thanks.Correct. MARS in yukon is designed to solve this.
http://msdn.microsoft.com/library/en-us/dnsql90/html/MARSinSQL05.asp?frame=true
--
-oj
"Thomas Brown" <ThomasBrown@.discussions.microsoft.com> wrote in message
news:B495E631-3D88-4880-B678-6E7F6DF9749C@.microsoft.com...
> When an ADO command does not exhaust the default result set and a second
> command is executed, the sqloledb provider automatically spawns a new
> session
> to execute the second command (using the default result set). My question
> is
> since command2 was definied on the connection (and prepared = true),
> should
> one be allowed to rebind a paramter on command2 and execute again? Doing
> so
> results in the following error -
> "Multiple-step OLD DB operator generated errors. Check each OLE DB status
> value, if available. No work was done."
> pseudo code example:
> cmd1.execute
> while not rs1.eof
> obtain row value, bind into cmd2
> cmd2.execute
> First execute works, second iteration fails.
> The solution is to shutdown cmd2 within the loop and recreate the command
> for each execution.
> Is this the expected behavior because of the inconsistent state for the
> command (having been spawned to a new session)?
> I know 2005 solves this issues w/ MARS.
> Thanks.
>

default result set semantics

When an ADO command does not exhaust the default result set and a second
command is executed, the sqloledb provider automatically spawns a new sessio
n
to execute the second command (using the default result set). My question is
since command2 was definied on the connection (and prepared = true), should
one be allowed to rebind a paramter on command2 and execute again? Doing so
results in the following error -
"Multiple-step OLD DB operator generated errors. Check each OLE DB status
value, if available. No work was done."
pseudo code example:
cmd1.execute
while not rs1.eof
obtain row value, bind into cmd2
cmd2.execute
First execute works, second iteration fails.
The solution is to shutdown cmd2 within the loop and recreate the command
for each execution.
Is this the expected behavior because of the inconsistent state for the
command (having been spawned to a new session)?
I know 2005 solves this issues w/ MARS.
Thanks.Correct. MARS in yukon is designed to solve this.
[url]http://msdn.microsoft.com/library/en-us/dnsql90/html/MARSinSQL05.asp?frame=true[/u
rl]
-oj
"Thomas Brown" <ThomasBrown@.discussions.microsoft.com> wrote in message
news:B495E631-3D88-4880-B678-6E7F6DF9749C@.microsoft.com...
> When an ADO command does not exhaust the default result set and a second
> command is executed, the sqloledb provider automatically spawns a new
> session
> to execute the second command (using the default result set). My question
> is
> since command2 was definied on the connection (and prepared = true),
> should
> one be allowed to rebind a paramter on command2 and execute again? Doing
> so
> results in the following error -
> "Multiple-step OLD DB operator generated errors. Check each OLE DB status
> value, if available. No work was done."
> pseudo code example:
> cmd1.execute
> while not rs1.eof
> obtain row value, bind into cmd2
> cmd2.execute
> First execute works, second iteration fails.
> The solution is to shutdown cmd2 within the loop and recreate the command
> for each execution.
> Is this the expected behavior because of the inconsistent state for the
> command (having been spawned to a new session)?
> I know 2005 solves this issues w/ MARS.
> Thanks.
>