Problem Executing Stored Procedures

We have an application that uses SQL-DMO to get a directory/file list for
the server by calling extended stored procedures, xp_availablemedia and
xp_cmdshell.
The app can successfully navigate the directories on systems running MSDE on
Window 2000 Professional, however, it fails to do so on systems running
Windows XP Professional.
There are no differences in the environment the application runs in other
than the version of Windows. Some of the characteristics of the
installation are: The application and MSDE are installed using the same
scripts on both versions of Windows. The systems where the app is installed
are running as part of a workgroup rather than a domain. We have run
svrnetcn.exe and verified that named pipes and TCP/IP are both enabled. To
confirm SQLDMO is enabled SQLDMO.DLL has been registered successfully from
the command line. Also, we can successfully execute the stored procedures
using SQL statements so it appears that the problems are related to SQLDMO.
Is there something additional or different that needs to be done on XP than
on 2000? Does anyone have any suggestions about how to solve this problem?
Thanks,
Tom
hi Tom,
"news.microsoft.com" <tom@.nospam.waspbarcode.com> ha scritto nel messaggio
news:erdTNo4EEHA.2740@.TK2MSFTNGP11.phx.gbl...
> We have an application that uses SQL-DMO to get a directory/file list for
> the server by calling extended stored procedures, xp_availablemedia and
> xp_cmdshell.
> The app can successfully navigate the directories on systems running MSDE
on
> Window 2000 Professional, however, it fails to do so on systems running
> Windows XP Professional.
> There are no differences in the environment the application runs in other
> than the version of Windows. Some of the characteristics of the
> installation are: The application and MSDE are installed using the same
> scripts on both versions of Windows. The systems where the app is
installed
> are running as part of a workgroup rather than a domain. We have run
> svrnetcn.exe and verified that named pipes and TCP/IP are both enabled.
To
> confirm SQLDMO is enabled SQLDMO.DLL has been registered successfully from
> the command line. Also, we can successfully execute the stored procedures
> using SQL statements so it appears that the problems are related to
SQLDMO.
> Is there something additional or different that needs to be done on XP
than
> on 2000? Does anyone have any suggestions about how to solve this
problem?
I do currently use SQL-DMO with success both on Win2k, WinXP pro and Win2003
server std...
I never had the need to manually register this somponent when installing
MSDE, and both procedures you are mentioning are run with success...
just the usual caveat... does the account running SQL Server and SQL Server
Agent have the right privileges?
did you try some simple SQL-DMO code to test it?
Andrea Montanari (Microsoft MVP - SQL Server)
http://www.asql.biz/DbaMgr.shtmhttp://italy.mvps.org
DbaMgr2k ver 0.7.0 - DbaMgr ver 0.53.0
(my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
interface)
-- remove DMO to reply
|||My guess is that it has nothing to do with SQL-DMO, but is instead a
permissions issue. xp_cmdshell has some rather strict permission issues when
being invoked (its all in the BOL). By default, XP has a tighter security
setup than Win2k, so this may be part of the root of your problem. The fact
that you are running in a Workgroup network may also be a factor, since its
security model is much different than a domain network. Have you tried
running the profiler against the system when running your application
against MSDE on XP?
Jim
"news.microsoft.com" <tom@.nospam.waspbarcode.com> wrote in message
news:erdTNo4EEHA.2740@.TK2MSFTNGP11.phx.gbl...
> We have an application that uses SQL-DMO to get a directory/file list for
> the server by calling extended stored procedures, xp_availablemedia and
> xp_cmdshell.
> The app can successfully navigate the directories on systems running MSDE
on
> Window 2000 Professional, however, it fails to do so on systems running
> Windows XP Professional.
> There are no differences in the environment the application runs in other
> than the version of Windows. Some of the characteristics of the
> installation are: The application and MSDE are installed using the same
> scripts on both versions of Windows. The systems where the app is
installed
> are running as part of a workgroup rather than a domain. We have run
> svrnetcn.exe and verified that named pipes and TCP/IP are both enabled.
To
> confirm SQLDMO is enabled SQLDMO.DLL has been registered successfully from
> the command line. Also, we can successfully execute the stored procedures
> using SQL statements so it appears that the problems are related to
SQLDMO.
> Is there something additional or different that needs to be done on XP
than
> on 2000? Does anyone have any suggestions about how to solve this
problem?
> Thanks,
> Tom
>
|||Andrea,
Both SQL Server and Agent are running under the Local System account so they
should have enough privileges.
The same application that is having problems with SQL-DMO also uses SQL-DMO
to do backups and restores and doesn't have any problems.
Tom
"Andrea Montanari" <andrea.sqlDMO@.virgilio.it> wrote in message
news:c43nsp$2cuegu$1@.ID-207518.news.uni-berlin.de...
> hi Tom,
> "news.microsoft.com" <tom@.nospam.waspbarcode.com> ha scritto nel messaggio
> news:erdTNo4EEHA.2740@.TK2MSFTNGP11.phx.gbl...
for
MSDE
> on
other
> installed
> To
from
procedures
> SQLDMO.
> than
> problem?
> I do currently use SQL-DMO with success both on Win2k, WinXP pro and
Win2003
> server std...
> I never had the need to manually register this somponent when installing
> MSDE, and both procedures you are mentioning are run with success...
> just the usual caveat... does the account running SQL Server and SQL
Server
> Agent have the right privileges?
> did you try some simple SQL-DMO code to test it?
> --
> Andrea Montanari (Microsoft MVP - SQL Server)
> http://www.asql.biz/DbaMgr.shtmhttp://italy.mvps.org
> DbaMgr2k ver 0.7.0 - DbaMgr ver 0.53.0
> (my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
> interface)
> -- remove DMO to reply
>
|||Jim,
Unfortunately, we have no control over the environment where the application
is being run, but, it is usually installed on stand-alone systems or
pier-to-pier networks that are not part of a domain.
Since we can execute the extended stored procedures in SQL commands, we are
in the process of converting the application so it doesn't use SQL-DMO
except for the backup and restore.
Tom
"J Young" <thorium48@.hotmail.com> wrote in message
news:OTbnG4OFEHA.2052@.TK2MSFTNGP11.phx.gbl...
> My guess is that it has nothing to do with SQL-DMO, but is instead a
> permissions issue. xp_cmdshell has some rather strict permission issues
when
> being invoked (its all in the BOL). By default, XP has a tighter security
> setup than Win2k, so this may be part of the root of your problem. The
fact
> that you are running in a Workgroup network may also be a factor, since
its
> security model is much different than a domain network. Have you tried
> running the profiler against the system when running your application
> against MSDE on XP?
> Jim
> "news.microsoft.com" <tom@.nospam.waspbarcode.com> wrote in message
> news:erdTNo4EEHA.2740@.TK2MSFTNGP11.phx.gbl...
for
MSDE
> on
other
> installed
> To
from
procedures
> SQLDMO.
> than
> problem?
>