I am in the process of converting an asp file into vbs and I am hitting a major problem
The line I am getting the error in is simple and is the first line of code
sDBName = Server.MapPath("../mydatabase.accdb")
returns
Microsoft VBScript runtime error: Object required 'Server'
The asp code page works fine when run as normal and I understand the need to remove "Server" from the likes of Server.CreateObject but I know that Server.MapPath should be allowed
I had another problem involving the Provider ACE.OLEDB.12.... but from this forum realised the problem was that I am using a x64 windows 2003 server. The "cscript" fix has not helped in this instance though.
PLEASE PLEASE HELP
Dave
The Server object is part of the ASP scripting environment and isn't generally available for stand-alone VBS scripts.
Also, the MapPath() method is used with respect to a web application's physical location on a server, and doesn't make sense for stand-alone VBS scripts.
Related
I have a COM component that I would like to use from Classic ASP. It is registered correctly using both the 64 and 32 bit version of regasm, using the /codebase switch.
All assemblies are signed with a strong name (although the key is not protected with a password). When I register the types, I get a confirmation that they were registered successfully.
If I make a VBScript file that attempts to create the COM component, it succeeds without issues when I run it with both the 64 and the 32 bit version of cscript.exe.
However, when I try to do a Server.CreateObject on the exact same COM component, I get the following error:
Server object error 'ASP 0177 : 80070002'
Server.CreateObject Failed
somefile.asp, line 2
80070002
The line provided by the excepton just contains the Server.CreateObject statement.
The assembly is AnyCPU, and the type I am trying to expose has a [ComVisible(true)] attribute set on it. The rest of the assembly is not COM visible.
Any clue on what I am experiencing here? I tried giving full permission to Everyone for the DLL files because I originally thought it was an IIS issue. However, that simply doesn't seem to be the case.
I have Googled this for many hours and seen countless similar questions, but this is not related, since none of the proposed solutions work.
If it works correctly with cscript.exe and failed in ASP, almost all the time that is due to the security context or file/register permission issue. ASP runs under the IIS user realm, and you will need to ensure that user ID has access to all the resources (including temp file/folder) needed for your COM object.
I solved it, but as I suspected, it wasn't the same cause as seen in other questions.
Apparently if you try to register a DLL from a network share, it will provide those symptoms, although the message is "Types registered successfully".
Very scary.
When moving all my DLLs to a local folder on the machine, they registered and ran successfully without issues.
I have zero knowledge of classic ASP and unfortunately I have been given the task of getting a legacy .net webforms/classic asp site up and running. I am almost there (I think) however I am getting an error on this line
set objAppContext = Server.CreateObject( "P21Dat.AppContext" )
Here is the error
Server object error 'ASP 0177 : 8007007e'
Server.CreateObject Failed
/siteconfig.asp, line 71
8007007e
I have no idea what "P21Dat.AppContext" is any help?
99.99% that ActiveX "P21Dat.AppContext" not registered on your machine.
0.01% that you don't have permission ;)
You could try to find in in registry...
You could use OleView program (or "Ole-Com Object Viewer" program) to get information about this ActiveX component...
Even after uninstalling and re-installing it several times, my dll wasn't picked up by my ASP application.
I can clearly see it in Registry list. I even gave permission to that key to everyone but no go.
After several tries I found it was because my dll was on network drive.
I copied to my local machine, un-installed and re-installed from local drive and it started working.
We have created one .Net Assembly and made it accessible as COM object.When we are trying to expose any method of this object in ASP page we get an error "80131509". We are not getting any error when we are instantiating the Object. i.e. Server.CreateObject is passing through.
This is working fine in our development environment but we are getting this error in UAT environment. Development and UAT are almost same except UAT is more secure. I have tried all possible ways but no luck. I am working on this issue for past 4 days and any help will be appreciated.
I am suspecting there may be some permission issue with IIS 7 on exposing that dll. But not sure what it can be? We have given full rights to IUSR too.
Code :
set obj = Server.CreateObject("DataAccess")
dim rs
set rs=obj.GetLocations("All") <--- **Here i am getting an error.**
We have a few com dll's at my work and we often run into problems where we register the dll with regasm and the dll does not work. It works in other live environments but for some reason it just will not work in this one instance. Com dlls are fickle. Sometimes we will register it, unregister it, re-register it, and reboot. Sometimes they mysteriously start working other times not.
There are a couple more things that can go wrong.
Make sure that the correct permissions are set on the folders the dll lives in and on the dll itself. Also make sure that any dependent dlls are present and also have the correct permission. Ensure that everything the dll needs access to also has the correct permissions.
If that fails open regedit. Search for the guid associated with the com object. Sometimes you will discover that the paths the registry have are all mixed up. Clean out any references to the com object, reboot, and re-register it.
I have also seen an exception being thrown in the constructor causing issues. When the com object starts up it blows up. In one of our objects added a method to send an email when an exception occurs.
In one case we had an old com object that was no longer compatible with the version of windows we were running. If you have upgraded the server it is on that could be the problem. In our case we wrote our own component to replace the broken old one.
Also make sure that if the com object is strongly typed that you use the "regasm /tlb /codebase fickle_com_object.dll"
In short there are several things that cause com object to not work:
Multiple paths in the registry
Wrong security permissions on folders
Crashing when being created
Perhaps one of these things will solve your issue. I know how difficult it can be sometimes. Good luck!
Sorry about the mishmash of words in the title, but that's how confused I am. I can't even summarize the error I'm getting in a simple sentence.
This flex/amfphp application works fine on my computer, even though it accesses an Oracle database on another server. However, when I try to access it from another computer, this is the error I get. I'll try and put the most relevant code in. (My browser tell me this is an ActionScript error).
Fault faultString="Send failed"
faultCode="Client.Error.MessageSend"
faultDetail="Channel.Security.Error error Error #2048: Security Area Violation..
Couldn't load data from http://localhost/.../amfphp/gateway.php
As I said before, it works on my machine for some reason. Now, when I try to access this remotely from other machines, it seems that the PHP engine is looking for gateway.php on the localhost of that machine?? Does this mean that PHP is looking for gateway.php on the client's localhost rather than on the server??
Correct me if I'm wrong, and thanks in advance
Your services-config.xml in Flex propably points to http://localhost/.../amfphp/gateway.php
You'll need to change the endpoint in that XML file and recompile the application.
You could also create your ChannelSet at runtime. In that case you don't need the services-config.xml anymore. Take a look at http://raghuonflex.wordpress.com/2008/06/05/endpointatruntime/ for some inspiration...
I have been trying to work on integrating a NewsLetter for a companies local intranet and I keep running into the same error that everyone seems to be getting. I am running this on IIS 5.1 and on error exists at Server.CreateObject(ADODB.Connection), also the purpose of the ASP code is to read an Excel file
Error Type:
Server object, ASP 0196 (0x80040154)
Only InProc server components should be used. If you want to use LocalServer components, you must set the AspAllowOutOfProcComponents metabase setting. Please consult the help file for important considerations.
I have tried the solution to locate to my AdminScripts directory and setting the boolean value to True with cscript adsutil.vbs set /w3svc/aspallowoutofproccomponents True and then verified by cscript adsutil.vbs enum /w3svc > verified.txt
Opening up the textfile, it does show that the value is set to true but I run into the same error again when trying to access the ASP page. I am at a loss, I figured after reading all those people post questions that I'd ask the question myself.
I cringe at the sight of that error messages, please make my nightmare end.
Its a bizare error to be getting in the first place. Why would the simple ADODB.Connection object be considered an out-of-process component?
The only thing I can think of that might cause this is if someone has accidently dragged the ADO dll into a COM+ Service. Check the set of COM+ Services anything unusual installed there?
In an attempt to repair you could download the latest MDAC from Microsoft's download area and re-install it on your machine.
Enabling out-of-proc components to is not the answer ADODB.Connection should not be out-of-proc.
Next Step
Fire up Regedit, find in Keys the key value of {00000514-0000-0010-8000-00AA006D2EA4} under
HKEY_CLASSES_ROOT
You should find an InprocServer32 key with a default value: C:\Program Files\Common Files\system\ado\msado15.dll
The ProgID should ADODB.Connection.2.8.
I had to use:
Regsvr32.exe "C:\Program Files\Common Files\system\ado\Msado15.dll"
in the command window to have the InProcServer32 key appear, thank you Anthony.
Everything is up and working now. My nightmares are over!