Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion Groups
DB Engine
SQL ServerMSDESQL Server CE
Services
Analysis (Data Mining)Analysis (OLAP)DTSIntegration ServicesNotification ServicesReporting Services
Programming
CLRConnectivitySQLXML
Other Technologies
ClusteringEnglish QueryFull-Text SearchReplicationService Broker
General
Data WarehousingPerformanceSecuritySetupSQL Server ToolsOther SQL Server Topics
DirectoryUser Groups
Related Topics
MS AccessOther DB ProductsMS Server Products.NET DevelopmentVB DevelopmentJava DevelopmentMore Topics ...

SQL Server Forum / General / Security / October 2005

Tip: Looking for answers? Try searching our database.

xplog70.dll

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
szv584 - 14 Oct 2005 22:58 GMT
Hi!

I'm not sure if this is the right group but I give it a try:

I have a job that executes a DTS-package which in turn call a store procedure
which calls another store procedure. The last procedure calls xplog70.dll
passing a filename (full path) to get some information back about the file.
This has worked for a long time without any trouble but it stopped working
after we have patch the server with the latest patches from Microsoft
(atleast that is the theory) -

MS05-050
MS05-051
MS05-052
MS05-046
MS05-047
MS05-048
MS05-049
MS05-044
MS05-045

Also, if you ignore the job and execute the whole "chain" from the DTS
package the result is the same. However, if you start the "chain" by
executing the first store procedure from Query Analyzer it works fine.

When this fails the result from xplog.70.dll is nothing.
Running the job as system administrator (windows account) or database owner
gives the same "bad" result.

Any ideas that can explain why i works from QA but running the job or DTS?

Thank's in advance
Bjorn
Sue Hoegemeier - 18 Oct 2005 06:00 GMT
What extended stored procedure are you calling from
xplog70.dll? You wouldn't really (shouldn't really) be
calling the dll directly but rather one of the extended
stored procedures in that dll.

-Sue

>Hi!
>
[quoted text clipped - 29 lines]
>Thank's in advance
>Bjorn
szv584 - 18 Oct 2005 10:33 GMT
Hi Sue!

We call it by using the extended procudure  xp_cmdshell. From what we have
found out so far, there seems to be some problems with the patchMS05-051 and
maybe that is our problem. I give you the link below. If you have any other
ideas, they are more then welcome.

Regards
Björn
http://news.com.com/Critical+Windows+patch+may+wreak+PC+havoc/2100-1002_3-589604
1.html?tag=nefd.top


http://support.microsoft.com/kb/909444

>What extended stored procedure are you calling from
>xplog70.dll? You wouldn't really (shouldn't really) be
[quoted text clipped - 8 lines]
>>Thank's in advance
>>Bjorn
Sue Hoegemeier - 18 Oct 2005 13:06 GMT
Try logging onto the server under the windows account that
the Agent service account is running under. Then use QA on
the server to try to execute the process that runs fine when
you run it from QA. That will emulated the execution
location (the server) and the security context it runs under
when run as a job. You really can't tell otherwise. Also,
turn on package logging for the DTS package to check for
errors. In addition, check the event logs on the server - I
don't think you'll have anything but it's worth checking as
well.

-Sue

>Hi Sue!
>
[quoted text clipped - 21 lines]
>>>Thank's in advance
>>>Bjorn
szv584 - 18 Oct 2005 17:47 GMT
Will do that.

Thank's

/Björn

>Try logging onto the server under the windows account that
>the Agent service account is running under. Then use QA on
[quoted text clipped - 14 lines]
>>>>Thank's in advance
>>>>Bjorn
szv584 - 20 Oct 2005 10:25 GMT
We did a reset on the sql proxy account and now everything is working again.

>Will do that.
>
[quoted text clipped - 7 lines]
>>>>>Thank's in advance
>>>>>Bjorn
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2010 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.