I am currently trying to move a web site fr开发者_如何学编程om one server to another, one of the asp pages contains some vb script that looks like this:
Dim oSearch 'AS Object
Dim strXML 'AS String
Dim strXSL 'AS String
Dim oRS 'AS ADODB.RecordSet
Set oSearch = Server.CreateObject("ETHERNET_PL.CETHERNET_PL")
strXSL = Server.MapPath("EthernetSearch.xsl")
strXML = oSearch.ServeSearch(strXSL,1,1000,0)
Set oSearch= Nothing
Set oRS=Nothing
Response.Write strXML
My knowledge of this technology is very limited, but I can say that "ETHERNET_PL.CETHERNET_PL" is a component service on both servers that does indeed have a method called ServeSearch. Also the EthernetSearch.xsl file does exist on both servers. The only problem is that on the new server I receive the following error when I attempt to visit the page:
msxml3.dll error '8000000a'
The data necessary to complete this operation is not yet available.
/EthernetSearch.asp, line 63
Where line 63 is:
strXML = oSearch.ServeSearch(strXSL,1,1000,0)
Does anybody know what would be causing these two pages to function differently on two different servers?
Thanks in advance
There's a few forum discussions around the web that suggest this error might be due to the fact that MSXML is not loading the data fast enough (or it times out while loading the data) which leads to errors when it tries to use it e.g. http://forums.devx.com/archive/index.php/t-100302.html
Since this error is coming from the ETHERNET_PL.CETHERNET_PL
component then this is an issue with it's internal use of MSXML
You said that the XML file exists on both servers but is it the same file, is the one on the server giving the error significantly bigger such that loading times could be an issue?
It appears that Microsoft XML is not finding the data. The problem could be in numerous areas of the system. I would start looking at:
- configuration files for ETHERNET_PL.CETHERNET_PL app on the machines - if it has its own config - compare them. This might shed some light on how it's using MSXML. If you have access to this component play with it separately to learn its usage and debug it on its own if you can.
Then the "regular" checks like ...
- file system, NTFS permissions on the XML data file, on the website, etc.
- ensure all installed software versions are the same (IIS, MSXML, ETHERNET_PL, VBScript and any others)
- check IIS settings across machines - e.g. is the web app on one server running in debug mode, but not on ther other? etc.
- Windows Registry permissions for any of the softwares already listed - if any settings are stored there (the Windows registry has its own set of ACL permissions on its nodes). Run regedit.exe
Also Google your error message. It's time consuming to filter through these results but you're using older technology so likely if the issue has been experienced by somebody else the answer will be online or a plethora of suggestions, not unlike those listed above. Very good chance of having it solved this way.
If you need to, set everything up again on a clean machine or inside a virtual machine and then start retracing your steps on the buggy machine on which the problem occurs - this is time consuming but can lead you to look into details that you wouldn't otherwise.
精彩评论