MSDE and Computer Name Change

Hi!
I know that the default instance of MSDE is the computer name. If the
computer's name is subsequently changed, will the default instance’s name
change to the new computer name as well.
Thanks for your thoughts.
Actually the default instance name is not the computer name. All instances
are addressed in connections strings as <computer name>\<instance name>. If
you leave off the instance name then SQL Server assumes you are talking
about the default instance. So yes, if you change the computer name, all
your connection strings will break, probably including some that you aren't
aware of so changing the computer name is a risky thing to do. At a minimum
you will nee to use sp_addserver and restart MSDE to change SQL Server's
local server name.
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Gene" <Gene@.discussions.microsoft.com> wrote in message
news:85740AA2-9F4B-4CF8-B304-E27782458703@.microsoft.com...
> Hi!
> I know that the default instance of MSDE is the computer name. If the
> computer's name is subsequently changed, will the default instance's name
> change to the new computer name as well.
> Thanks for your thoughts.
|||Thanks for the input Roger. I don't know much about SQL, but my guess would
have been pretty close to your response. I'm concerned about breaking
something I'm not aware of and not knowing where to go from there.
Regards,
Gene
"Roger Wolter[MSFT]" wrote:

> Actually the default instance name is not the computer name. All instances
> are addressed in connections strings as <computer name>\<instance name>. If
> you leave off the instance name then SQL Server assumes you are talking
> about the default instance. So yes, if you change the computer name, all
> your connection strings will break, probably including some that you aren't
> aware of so changing the computer name is a risky thing to do. At a minimum
> you will nee to use sp_addserver and restart MSDE to change SQL Server's
> local server name.
> --
> This posting is provided "AS IS" with no warranties, and confers no rights.
> Use of included script samples are subject to the terms specified at
> http://www.microsoft.com/info/cpyright.htm
> "Gene" <Gene@.discussions.microsoft.com> wrote in message
> news:85740AA2-9F4B-4CF8-B304-E27782458703@.microsoft.com...
>
>
sql

MSDE 2000a installation failure on XP Pro

Hi,
Everyone know why MSDE 2000a is refusing to load on a XP Pro wiht Office SBS installed on it. It seems to have MSDE already but the default instance isn't accessible so I tried to install under another instance name. I have set the SA password.
File and print sharing is installed and running (I think). I'm able to share out folders.
Any suggestions?
Jim
Posted using Wimdows.net NntpNews Component -
Post Made from http://www.SqlJunkies.com/newsgroups Our newsgroup engine supports Post Alerts, Ratings, and Searching.
hi Jim,
"SqlJunkies User" <User@.-NOSPAM-SqlJunkies.com> ha scritto nel messaggio
news:eIKtRH8eEHA.3028@.TK2MSFTNGP12.phx.gbl...
> Hi,
> Everyone know why MSDE 2000a is refusing to load on a XP Pro wiht Office
SBS installed on it. It seems to have MSDE already but the default instance
isn't accessible so I tried to install under another instance name. I have
set the SA password.
> File and print sharing is installed and running (I think). I'm able to
share out folders.
I'm not aware of such limitation... but, anyway, please add the /L*v
"c:\..\Log.txt" command line parameter in order to
inspect the resulting log file..
Andrea Montanari (Microsoft MVP - SQL Server)
http://www.asql.biz/DbaMgr.shtmhttp://italy.mvps.org
DbaMgr2k ver 0.8.0 - DbaMgr ver 0.54.0
(my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
interface)
-- remove DMO to reply
sql

MSDE 2000 Named instance in conjunction with SQL server 7

I have SQL server 7 running as a default instance and I'm trying to install
MSDE 2000. I was able to install it as a named instance by running the
following:
setup.exe SAPWD="password" INSTANCENAME="named_instance"
Now I can not connect to the named instance with OSQL. What do I need to do
to connect properly?
Hi,
Try to connect to the instance as servername\named_instance
Example: If your machine name is MyServer1 and your named instance is
Cyclops then you would refer to the server as MyServer1\Cyclops. If this
will not work for you in the long run, you can always set up an alias on
your client through the Client Network Utility to refer to it in a more
conventional manner.
-Jose Molina
"iranpessar@.hotmail.com" <iranpessarhotmailcom@.discussions.microsoft.com>
wrote in message news:1FB9C0FC-639B-4B6E-A4EC-6623B70F3F78@.microsoft.com...
>I have SQL server 7 running as a default instance and I'm trying to install
> MSDE 2000. I was able to install it as a named instance by running the
> following:
> setup.exe SAPWD="password" INSTANCENAME="named_instance"
> Now I can not connect to the named instance with OSQL. What do I need to
> do
> to connect properly?

MSDE 2000 Named instance in conjunction with SQL server 7

I have SQL server 7 running as a default instance and I'm trying to install
MSDE 2000. I was able to install it as a named instance by running the
following:
setup.exe SAPWD="password" INSTANCENAME="named_instance"
Now I can not connect to the named instance with OSQL. What do I need to do
to connect properly?Hi,
Try to connect to the instance as servername\named_instance
Example: If your machine name is MyServer1 and your named instance is
Cyclops then you would refer to the server as MyServer1\Cyclops. If this
will not work for you in the long run, you can always set up an alias on
your client through the Client Network Utility to refer to it in a more
conventional manner.
-Jose Molina
"iranpessar@.hotmail.com" <iranpessarhotmailcom@.discussions.microsoft.com>
wrote in message news:1FB9C0FC-639B-4B6E-A4EC-6623B70F3F78@.microsoft.com...
>I have SQL server 7 running as a default instance and I'm trying to install
> MSDE 2000. I was able to install it as a named instance by running the
> following:
> setup.exe SAPWD="password" INSTANCENAME="named_instance"
> Now I can not connect to the named instance with OSQL. What do I need to
> do
> to connect properly?sql

MSDE & SQL Server 2000

I have MSDE 2000 SP3a (default instance) installed and working on my XP Pro
machine, but I'd like to follow some development labs that use the SQL Server
2000 databases. Can I also install SQL Server 2000 3a and if so, what special
'things' must I do to install it?
Dale Cowan
hi Dale,
"Dale" <Dale@.discussions.microsoft.com> ha scritto nel messaggio
news:D5AC5D41-BAA8-4502-B847-06DD990929CF@.microsoft.com...
> I have MSDE 2000 SP3a (default instance) installed and working on my XP
Pro
> machine, but I'd like to follow some development labs that use the SQL
Server
> 2000 databases. Can I also install SQL Server 2000 3a and if so, what
special
> 'things' must I do to install it?
you can only install SQL Server 2000 Developer edition, Personal Edition and
MSDE, on Windows clients platforms... the Standard and Enterprise edition
are only for server platforms...
as long as you install a supported version, you only have to specify a named
instance installation, as your pc already hosts a default instance.
you can have different service pack levels (never tried different localized
versions, but may be =;-D), but the shared binaries in \Program
Files\Microsoft SQL Server\80 folders will be updated at the highes
installed service pack level.
at the moment there's no SQL Server service pack 3 installation, you have to
install the RTM and apply the desired service pack
Andrea Montanari (Microsoft MVP - SQL Server)
http://www.asql.biz/DbaMgr.shtmhttp://italy.mvps.org
DbaMgr2k ver 0.9.1 - DbaMgr ver 0.55.1
(my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
interface)
-- remove DMO to reply
|||RTM?
"Andrea Montanari" wrote:

> hi Dale,
> "Dale" <Dale@.discussions.microsoft.com> ha scritto nel messaggio
> news:D5AC5D41-BAA8-4502-B847-06DD990929CF@.microsoft.com...
> Pro
> Server
> special
> you can only install SQL Server 2000 Developer edition, Personal Edition and
> MSDE, on Windows clients platforms... the Standard and Enterprise edition
> are only for server platforms...
> as long as you install a supported version, you only have to specify a named
> instance installation, as your pc already hosts a default instance.
> you can have different service pack levels (never tried different localized
> versions, but may be =;-D), but the shared binaries in \Program
> Files\Microsoft SQL Server\80 folders will be updated at the highes
> installed service pack level.
> at the moment there's no SQL Server service pack 3 installation, you have to
> install the RTM and apply the desired service pack
> --
> Andrea Montanari (Microsoft MVP - SQL Server)
> http://www.asql.biz/DbaMgr.shtmhttp://italy.mvps.org
> DbaMgr2k ver 0.9.1 - DbaMgr ver 0.55.1
> (my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
> interface)
> -- remove DMO to reply
>
|||hi Dale,
"Dale" <Dale@.discussions.microsoft.com> ha scritto nel messaggio
news:610C1A77-A467-4BD9-92E5-BE5B5961AEC2@.microsoft.com...
> RTM?
Release To Manufacturer =;-D
the 1st at al retail version
Andrea Montanari (Microsoft MVP - SQL Server)
http://www.asql.biz/DbaMgr.shtmhttp://italy.mvps.org
DbaMgr2k ver 0.9.1 - DbaMgr ver 0.55.1
(my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
interface)
-- remove DMO to reply
|||Thanks for your help. Everything installed just fine - even MS03-031 security
update afterward. MBSA reports few problems.
"Andrea Montanari" wrote:

> hi Dale,
> "Dale" <Dale@.discussions.microsoft.com> ha scritto nel messaggio
> news:610C1A77-A467-4BD9-92E5-BE5B5961AEC2@.microsoft.com...
> Release To Manufacturer =;-D
> the 1st at al retail version
> --
> Andrea Montanari (Microsoft MVP - SQL Server)
> http://www.asql.biz/DbaMgr.shtmhttp://italy.mvps.org
> DbaMgr2k ver 0.9.1 - DbaMgr ver 0.55.1
> (my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
> interface)
> -- remove DMO to reply
>

MSDE & datadir

Is it possible that on the client's machine I install my MSDE instance in the default location (C:\Program Files\Microsoft SQL Server), i.e. do not specify any datadir or Targetdir location in the setup BUT still create my app's database (during installat
ion) in my app's folder, for e.g. in C:\Program Files\MyCompany\Data\ folder and then attach this database's .mdf file to my instance which I installed. Is it necessary that the database has to be in the data folder under the MSDE install location...
Please suggest.
I am asking because I want to have nothing but database in the my app's data folder.
>> still create my app's database (during installation) in my app's folder
Yes. This is possible. It is NOT mandated that the specific databases that
you create should also fall inside the default location. In event that you
create database without any specific paths then they are created in the
default location.
HTH,
Vinod Kumar
MCSE, DBA, MCAD, MCSD
http://www.extremeexperts.com
Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp
"qa" <anonymous@.discussions.microsoft.com> wrote in message
news:CC9D5500-4C13-45B6-9040-F4A908DAEB26@.microsoft.com...
> Is it possible that on the client's machine I install my MSDE instance in
the default location (C:\Program Files\Microsoft SQL Server), i.e. do not
specify any datadir or Targetdir location in the setup BUT still create my
app's database (during installation) in my app's folder, for e.g. in
C:\Program Files\MyCompany\Data\ folder and then attach this database's .mdf
file to my instance which I installed. Is it necessary that the database
has to be in the data folder under the MSDE install location...
> Please suggest.
> I am asking because I want to have nothing but database in the my app's
data folder.
|||Thanks Vinod for your reply. How can I specify path for the database (not the entire data folder) as C:\Program Files\MyCompany\Data\ while creating the database using scripts during the installation program. And is keeping the database away in myapp's
folder a recommended way of working..
qa
|||You have to specify the path to the database and log files in the CREATE
DATABASE statement of the script file. Example for a database called "HAS":
CREATE DATABASE [HAS] ON (NAME = N'HAS_Data', FILENAME = N'f:\Microsoft SQL
Server\MSSQL\data\HAS_Data.MDF' , SIZE = 2, FILEGROWTH = 10%) LOG ON (NAME =
N'HAS_Log', FILENAME = N'f:\Microsoft SQL Server\MSSQL\data\HAS_Log.LDF' ,
SIZE = 1, FILEGROWTH = 10%)
COLLATE Latin1_General_CI_AS
GO
Willem
"qa" <anonymous@.discussions.microsoft.com> schreef in bericht
news:A7253E41-0E31-4D5C-967F-E7483AE75304@.microsoft.com...
> Thanks Vinod for your reply. How can I specify path for the database (not
the entire data folder) as C:\Program Files\MyCompany\Data\ while creating
the database using scripts during the installation program. And is keeping
the database away in myapp's folder a recommended way of working..
> qa

msdb refuses to back up w/ plan

All,
I've created (and re-created) a Mx plan for the system databases.
Part of it is a complete backup. All the default options in the
wizard were chosen, including the option to verify.
Master and Model back up fine. MSDB, however, fails. According to
the Mx Plan log, the backup completes successfully, but the verify
fails as follows:
[Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 3201:
[Microsoft][ODBC SQL Server Driver][SQL Server]Cannot open backu
p
device 'd:\sql_data\MSSQL\BACKUP\msdb_db_200407
042207.BAK'. Device
error or device off-line. See the SQL Server error log for more
details.
[Microsoft][ODBC SQL Server Driver][SQL Server]VERIFY DATABASE i
s
terminating abnormally.
1- It doesn't appear that the backup actually succeeded, as there is
no msdb_db_200407042207.bak file in the directory.
2- There is no additional information in the SQL Server error log
3- I can successfully back up msdb -manually- without a hiccup.
I've tried:
1- Recreating a new Mx Plan from scratch (no effect)
2- Can full index/optimizations on msdb (no errors found)
3- Tried shrinking the database (it's 215MBish) to make it faster
4- Tried a full backup/restore of msdb in case it had any mystery
corruption (no effect)
Oh yes, SQL Server standard 2000 sp3 on W2.3K standard. NTFS
partition. SQL Agent using a domain account, SQL Server running under
the same account.
Can anyone shed light on this? I can come up with no reason why the
Mx plan would fail for just this one database, when I can back it up
just fine manually.
GeofHere's some more info:
I did find some additional information in the app event log, giving the spec
ific T-SQL that was failing:
BACKUP DATABASE [msdb] TO DISK = N'd:\sql_data\MSSQL\BACKUP\msdb_db_200
407042238.BAK' WITH INIT , NOUNLOAD , NOSKIP , STATS = 10, NOFORMAT
After some pondering and re-reading my own post, I went ahead and logged int
o the server interactively using SQL Server's account. I attempted to execu
te the above SQL and lo and behond, it failed (General Network Error). When
executed under my normal U
serID, it executed fine.
Trial and error then produced the rather odd discovery that the problem part
of the statement is the seemingly innocuous "STATS=10" command. If the sam
e statement is run under the SQL Server account EXCEPT for removing the stat
s=10 command, it works fine|||Go the Maintenance Plan and right click and view maintenance history out
there ...Thats where most of the reasoning is for the failure..
"Geof" <Geof@.discussions.microsoft.com> wrote in message
news:C6436F94-BF81-41FD-9869-5595F7FBA6B4@.microsoft.com...
> Here's some more info:
> I did find some additional information in the app event log, giving the
specific T-SQL that was failing:
> BACKUP DATABASE [msdb] TO DISK =
N'd:\sql_data\MSSQL\BACKUP\msdb_db_20040
7042238.BAK' WITH INIT , NOUNLOAD
, NOSKIP , STATS = 10, NOFORMAT
> After some pondering and re-reading my own post, I went ahead and logged
into the server interactively using SQL Server's account. I attempted to
execute the above SQL and lo and behond, it failed (General Network Error).
When executed under my normal UserID, it executed fine.
> Trial and error then produced the rather odd discovery that the problem
part of the statement is the seemingly innocuous "STATS=10" command. If the
same statement is run under the SQL Server account EXCEPT for removing the
stats=10 command, it works fine.
> While I've gotten more information on exactly what is causing the problem,
I:
> 1- Have no idea why the problem is occurring, and
> 2- Don't know a way around it (other than backup w/o using a Mx Plan)
> My nearest stab would be that this particular T-SQL (and STATS option in
particular) is causing some sort of collision between SQL Server and SQL
Server Agent since they would both be running under the same account. (But
surely I'm not the only one in the history of SQL Server to have created a
sysdb mx plan w/ both SQL and SQL Agent running under an identical domain
account, huh')
> Ideas'|||In my first post I listed what was in the Mx Plan History. Does
anyone have any other ideas?
Geof
"Hassan" <fatima_ja@.hotmail.com> wrote in message news:<#GDGyveYEHA.996@.TK2MSFTNGP12.phx.gbl
>...
> Go the Maintenance Plan and right click and view maintenance history out
> there ...Thats where most of the reasoning is for the failure..

msdb refuses to back up w/ plan

All,
I've created (and re-created) a Mx plan for the system databases.
Part of it is a complete backup. All the default options in the
wizard were chosen, including the option to verify.
Master and Model back up fine. MSDB, however, fails. According to
the Mx Plan log, the backup completes successfully, but the verify
fails as follows:
[Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 3201:
[Microsoft][ODBC SQL Server Driver][SQL Server]Cannot open backup
device 'd:\sql_data\MSSQL\BACKUP\msdb_db_200407042207.BAK '. Device
error or device off-line. See the SQL Server error log for more
details.
[Microsoft][ODBC SQL Server Driver][SQL Server]VERIFY DATABASE is
terminating abnormally.
1- It doesn't appear that the backup actually succeeded, as there is
no msdb_db_200407042207.bak file in the directory.
2- There is no additional information in the SQL Server error log
3- I can successfully back up msdb -manually- without a hiccup.
I've tried:
1- Recreating a new Mx Plan from scratch (no effect)
2- Can full index/optimizations on msdb (no errors found)
3- Tried shrinking the database (it's 215MBish) to make it faster
4- Tried a full backup/restore of msdb in case it had any mystery
corruption (no effect)
Oh yes, SQL Server standard 2000 sp3 on W2.3K standard. NTFS
partition. SQL Agent using a domain account, SQL Server running under
the same account.
Can anyone shed light on this? I can come up with no reason why the
Mx plan would fail for just this one database, when I can back it up
just fine manually.
Geof
Here's some more info:
I did find some additional information in the app event log, giving the specific T-SQL that was failing:
BACKUP DATABASE [msdb] TO DISK = N'd:\sql_data\MSSQL\BACKUP\msdb_db_200407042238.BA K' WITH INIT , NOUNLOAD , NOSKIP , STATS = 10, NOFORMAT
After some pondering and re-reading my own post, I went ahead and logged into the server interactively using SQL Server's account. I attempted to execute the above SQL and lo and behond, it failed (General Network Error). When executed under my normal U
serID, it executed fine.
Trial and error then produced the rather odd discovery that the problem part of the statement is the seemingly innocuous "STATS=10" command. If the same statement is run under the SQL Server account EXCEPT for removing the stats=10 command, it works fine
|||Go the Maintenance Plan and right click and view maintenance history out
there ...Thats where most of the reasoning is for the failure..
"Geof" <Geof@.discussions.microsoft.com> wrote in message
news:C6436F94-BF81-41FD-9869-5595F7FBA6B4@.microsoft.com...
> Here's some more info:
> I did find some additional information in the app event log, giving the
specific T-SQL that was failing:
> BACKUP DATABASE [msdb] TO DISK =
N'd:\sql_data\MSSQL\BACKUP\msdb_db_200407042238.BA K' WITH INIT , NOUNLOAD
, NOSKIP , STATS = 10, NOFORMAT
> After some pondering and re-reading my own post, I went ahead and logged
into the server interactively using SQL Server's account. I attempted to
execute the above SQL and lo and behond, it failed (General Network Error).
When executed under my normal UserID, it executed fine.
> Trial and error then produced the rather odd discovery that the problem
part of the statement is the seemingly innocuous "STATS=10" command. If the
same statement is run under the SQL Server account EXCEPT for removing the
stats=10 command, it works fine.
> While I've gotten more information on exactly what is causing the problem,
I:
> 1- Have no idea why the problem is occurring, and
> 2- Don't know a way around it (other than backup w/o using a Mx Plan)
> My nearest stab would be that this particular T-SQL (and STATS option in
particular) is causing some sort of collision between SQL Server and SQL
Server Agent since they would both be running under the same account. (But
surely I'm not the only one in the history of SQL Server to have created a
sysdb mx plan w/ both SQL and SQL Agent running under an identical domain
account, huh?)
> Ideas?
|||In my first post I listed what was in the Mx Plan History. Does
anyone have any other ideas?
Geof
"Hassan" <fatima_ja@.hotmail.com> wrote in message news:<#GDGyveYEHA.996@.TK2MSFTNGP12.phx.gbl>...
> Go the Maintenance Plan and right click and view maintenance history out
> there ...Thats where most of the reasoning is for the failure..

msdb refuses to back up w/ plan

All,
I've created (and re-created) a Mx plan for the system databases.
Part of it is a complete backup. All the default options in the
wizard were chosen, including the option to verify.
Master and Model back up fine. MSDB, however, fails. According to
the Mx Plan log, the backup completes successfully, but the verify
fails as follows:
[Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 3201:
[Microsoft][ODBC SQL Server Driver][SQL Server]Cannot open backup
device 'd:\sql_data\MSSQL\BACKUP\msdb_db_200407042207.BAK'. Device
error or device off-line. See the SQL Server error log for more
details.
[Microsoft][ODBC SQL Server Driver][SQL Server]VERIFY DATABASE is
terminating abnormally.
1- It doesn't appear that the backup actually succeeded, as there is
no msdb_db_200407042207.bak file in the directory.
2- There is no additional information in the SQL Server error log
3- I can successfully back up msdb -manually- without a hiccup.
I've tried:
1- Recreating a new Mx Plan from scratch (no effect)
2- Can full index/optimizations on msdb (no errors found)
3- Tried shrinking the database (it's 215MBish) to make it faster
4- Tried a full backup/restore of msdb in case it had any mystery
corruption (no effect)
Oh yes, SQL Server standard 2000 sp3 on W2.3K standard. NTFS
partition. SQL Agent using a domain account, SQL Server running under
the same account.
Can anyone shed light on this? I can come up with no reason why the
Mx plan would fail for just this one database, when I can back it up
just fine manually.
GeofHere's some more info:
I did find some additional information in the app event log, giving the specific T-SQL that was failing:
BACKUP DATABASE [msdb] TO DISK = N'd:\sql_data\MSSQL\BACKUP\msdb_db_200407042238.BAK' WITH INIT , NOUNLOAD , NOSKIP , STATS = 10, NOFORMAT
After some pondering and re-reading my own post, I went ahead and logged into the server interactively using SQL Server's account. I attempted to execute the above SQL and lo and behond, it failed (General Network Error). When executed under my normal UserID, it executed fine.
Trial and error then produced the rather odd discovery that the problem part of the statement is the seemingly innocuous "STATS=10" command. If the same statement is run under the SQL Server account EXCEPT for removing the stats=10 command, it works fine.
While I've gotten more information on exactly what is causing the problem, I:
1- Have no idea why the problem is occurring, and
2- Don't know a way around it (other than backup w/o using a Mx Plan)
My nearest stab would be that this particular T-SQL (and STATS option in particular) is causing some sort of collision between SQL Server and SQL Server Agent since they would both be running under the same account. (But surely I'm not the only one in the history of SQL Server to have created a sysdb mx plan w/ both SQL and SQL Agent running under an identical domain account, huh')
Ideas'|||Go the Maintenance Plan and right click and view maintenance history out
there ...Thats where most of the reasoning is for the failure..
"Geof" <Geof@.discussions.microsoft.com> wrote in message
news:C6436F94-BF81-41FD-9869-5595F7FBA6B4@.microsoft.com...
> Here's some more info:
> I did find some additional information in the app event log, giving the
specific T-SQL that was failing:
> BACKUP DATABASE [msdb] TO DISK =N'd:\sql_data\MSSQL\BACKUP\msdb_db_200407042238.BAK' WITH INIT , NOUNLOAD
, NOSKIP , STATS = 10, NOFORMAT
> After some pondering and re-reading my own post, I went ahead and logged
into the server interactively using SQL Server's account. I attempted to
execute the above SQL and lo and behond, it failed (General Network Error).
When executed under my normal UserID, it executed fine.
> Trial and error then produced the rather odd discovery that the problem
part of the statement is the seemingly innocuous "STATS=10" command. If the
same statement is run under the SQL Server account EXCEPT for removing the
stats=10 command, it works fine.
> While I've gotten more information on exactly what is causing the problem,
I:
> 1- Have no idea why the problem is occurring, and
> 2- Don't know a way around it (other than backup w/o using a Mx Plan)
> My nearest stab would be that this particular T-SQL (and STATS option in
particular) is causing some sort of collision between SQL Server and SQL
Server Agent since they would both be running under the same account. (But
surely I'm not the only one in the history of SQL Server to have created a
sysdb mx plan w/ both SQL and SQL Agent running under an identical domain
account, huh')
> Ideas'|||In my first post I listed what was in the Mx Plan History. Does
anyone have any other ideas?
Geof
"Hassan" <fatima_ja@.hotmail.com> wrote in message news:<#GDGyveYEHA.996@.TK2MSFTNGP12.phx.gbl>...
> Go the Maintenance Plan and right click and view maintenance history out
> there ...Thats where most of the reasoning is for the failure..