I am having to work in classic ASP for a small job.
I am trying to get the site running on my computer to test. I am running Windows 7 and IIS 7.
I get an error when running from local host and on checking the logs I get the error:
80004005 | Could_not_find_file_'c:\inetpub\wwwroot\sc\website\data\si.mdb'
My code is like so
dim objConn
dim objRS
set objConn = Server.CreateObject("ADODB.Connection")
objConn.Provider="Microsoft.Jet.OLEDB.4.0"
Set objRS = Server.CreateObject("ADODB.Recordset")
objConn.Open("c:/inetpub/wwwroot/sc/website/data/si.mdb")
This is the exact path to the file however.
Anyone know how I can access this? Is the code wrong or are there IIS settings I need to set?
I do not have any version of Office installed, would that cause a problem?
I have tried lots of different paths and provider settings but none have worked.
Edit
The code I am working on actually didn't have any connection string details in the code but the person said it still worked on thier computer as a friend setup the test environment.
He doesn't recall how his friend setup but said " What I remember from watching him, he connected to the database through Data Sources (ODBC) because as you said in the code theres no direct path as its using a 'global something' (dont know the right term)."
You could try using Process Monitor to see exactly which file is not being found or it is being caused by a permissions issue.
Also, although using forward slashes instead of backslashes isn't usually a problem, you may want to try changing that in case it makes any difference.
If you're using an x64 version of windows, JET is not supported in this mode, though you can get around it by configuring IIS to run x32 applications. To do this, run the following at the command line:
cscript.exe adsutil.vbs set W3SVC/AppPools/Enable32BitAppOnWin64 "true"
iisreset
The second command may not be required, but I'm guessing that you would probably need to restart IIS before this change takes effect.
It sounds like the code was previously set to use a global DSN, hence the lack of a path in the connection string, though there should have still been some kind of connection details (like the DSN name).
This may be a permissions issue.
An easy way to check would be to give full access to everyone for the directory the file is in.
Maybe you could use the Server.MapPath function as used here http://www.aspwebpro.com/tutorials/asp/dbconnectionopen.asp
Your connection string doesn't look right to me.
See if this helps.
EDIT: Do you have JET oledb provider installed?
EDIT2: Check for existence of oledb provider with help from this question.
How to check if an OLEDB driver is installed on the system?
I answered a potentially related question the other day. Are you running 64-bit windows 7? If so there is absolutely NO Jet support for x64 OSes. In a real .NET application you could simply recompile the application with x86 as the target. But in your case I am not sure of the solution.
Seth
Why does your string say:
"c:/inetpub/wwwroot/sc/website/data/si.mdb"
instead of the normal windows path
"c:\inetpub\wwwroot\sc\website\data\si.mdb"
Also, you could go to Control Panel->Administrative Tools->Data Source (ODBC) and create a new named DSN under the System tab. Name it si for example and make sure the type is access, give it the right path to the access db and then your code would just be:
dim objConn
set objConn = Server.CreateObject("ADODB.Connection")
objConn.Open("si")
Related
Sorry for possible dublicate.
I am trying to connect to my MySQL database from my LotusScript code (in some of my legacy projects):
Option Public
Option Declare
UseLSX "*LSXODBC"
Sub Initialize
Dim mysqlConnection As New ODBCConnection
Dim sqlQuery As New ODBCQuery
Dim result As New ODBCResultSet
Call mysqlConnection.ConnectTo("url","root","111111")
If Not mysqlConnection.IsConnected Then
MessageBox "No connection. Try again later."
Exit Sub
Else
MessageBox "Connection success."
End If
End Sub
I can't figure out what is the correct way to set the url of my database in LotusScript. I have already tried many variants of possible solutions, but nothing worked, also found many different urls, but also not helped.
Situation:
For example, I am trying to connect to my localhost MySQL base in port 3306 with name "test_db".
Question:
How must the url looks like for this?
p.s. also, if you have more possible ways to connect to MySQL DB from LotusScript - I will be very glad to see them.
Thanks.
As per the documentation for the ConnectTo method of ODBCConnetion class, you don't specify a URL. You specify a Data Source Name, otherwise known as a DSN. This is a name that you assign when you configure a connection in the 'Data Sources (ODBC)' tool on the Windows machine where the code will be executing.
On Windows 10, the 'Data Sources (ODBC)' tool is found in the Control Panel listed under Administrative Tools. On a Windows 2008 server that I happen to have handy, Administrative Tools is directly on the Start Menu. I'm sure they've hidden it in other places on other Windows versions. (I have a dim memory of it being under 'Accessories' on some versions.)
Note that on 64 bit versions of Windows, you need to be cognizant of whether your code is running in a 32 bit environment - as it is if it runs in the Notes client, or in a 64 bit environment, which it might be if it is running in background on a Domino server. There are separate 32 and 64 bit versions of the 'Data Sources (ODBC)' tool, and it does matter which one you use. If you're at all unsure, run them both and configure the same DSN name in each of them,
We have a POS system running a Firebird database and the rest of the business is on SYSPRO which is SQL Server based.
I would like to run queries and views between the databases as both databases have unique keys which can be matched.
Do I do this through a Linked Server? I have tried a few variations of linked server and I keep getting various error messages. So this is what I have so far:
EXEC master.dbo.sp_addlinkedserver
#server = N'OMNI',
#srvproduct=N'OMNI',
#provider=N'MSDASQL',
#datasrc=N'C:\Omni\Company\Data\databasefile.FDB',
#provstr=N'Driver={Firebird/InterBase(r) driver};Dbname=C:\Omni\Company\Data\databasefile.FDB;CHARSET=NONE;UID=SYSDBA;'
I have also tried connecting using Excel and I can see the database and view the tables using the following connection string:
Provider=MSDASQL.1;Persist Security Info=True;Data Source=Omni;Extended Properties="DSN=Omni;Driver={Firebird/InterBase(r) driver};Dbname=C:\Omni\Company\Data\databasefile.FDB;CHARSET=NONE;UID=SYSDBA;";Initial Catalog=Omni
Ok here is the answer (I have a short patch of hair left after this ;-) )
I cannot answer the technical questions as to why this works, but it works.
Firstly you need to install
Firebird 2.5
Then the 32 Bit Driver
32 Bit
Then the 64 Bit Driver
64 Bit
Then you go to you Command Prompt (administrator). Goto where you installed Firebird 2.5. In my case it was
C:\Program Files (x86)\Firebird\Firebird_2_5\bin\
Then enter:
fbguard.exe - a
This will get a version of the Firebird server going.
Then it is a simple setup of an ODBC link.
If you are trying to link to a local instance of the database, do not forget to put
localhost:\Company\Data\Companydata.fdb
The short answer is yes, it works (having the correct driver, sql side).
Let me try to simplify this scenario. In fact, it is not clear what kind of installation is the OP speaking about.
SQL Server must use either ODBC or OLE DB drivers. unfortunately, official Firebird drivers are dated 2017. Some third parties do them, devart, ibprovider, ibphonix, etc. I did my tests using the ibprovider ones.
The initial post is showing this connection string (partial): "Dbname=C:\Omni\Company\Data\databasefile.FDB".
Said that the traditional style for connecting via TCP/IP is
"IP address/port:database_file_path", the OP's seems to face with an embedded Firebird installation.
The difference is that, in this latter case, there is no Firebird service answering requests. Everything is done via a DLL, that's usually named fbembed.dll.
Installing Firebird as a service, as proposed, certainly fix the issue, because, after this installation, there is a (Windows) service always running and taking care of databases. However, if you do not want/need this service, MS SQL Server can work with the "embedded" installation too.
The main rule, I hardly discovered, is: the bunch of needed Firebird DLLs (but fbembed.dll) must be installed in the Windows system folder (in the manual it is reported exactly the contrary...).
To sum up, I have built a working server in this way.
0) I have benn always useing the ibprovider driver because their developers provide a great support service. And, some basic instructions can be found here too: https://www.ibprovider.com/eng/documentation/mssql_2012.html
1) I started downloading the official embedded package.
2) In the data folder, I have put the database, the fbembed.dll, and the firebird.msg
3) In the windows system folder, I have registered the minimum firebird DLL needed: icuuc30, icuin30, icudt30, and ib_util.
4) I've then created a linked server (yep, OPENROWSET is exactly the same) using the following string (if you need the fbclient.dll, simply copy/paste the embeded.dll and rename it):
EXEC master.dbo.sp_addlinkedserver #server = N'myName', #srvproduct=N'myName', #provider=N'LCPI.IBProvider.3', #datasrc=N'myName', #provstr=N'location=E:\mypath\MYDB.GDB;dbclient_library_64=E:\mypath\fbembed.dll;auto_commit=true;nested_trans=true;truncate_char=false;dbtime_rules=1;support_odbc_query=true;asynch_fetch=2;ignore_err_param=4;schema_ldr_cfg__check_constraints=0;schema_ldr_cfg__descriptions=0;dbclient_type=fb'
5) Security isn't a concern. The DLL does not manage it, BUT you need to pass a userid/password pair:
EXEC master.dbo.sp_addlinkedsrvlogin #rmtsrvname=N'myName',#useself=N'False',#locallogin=NULL,#rmtuser=N'SYSDBA',#rmtpassword='anytring'
6) you do need a couple of special options to be set to True: Collation, Allow inprocess, RPC, RPC Out.
Yes it works. And it saves at least a couple of MB ram as you haven't an always-run service.
Last but not least, thanks to the ibprovider.com developers that help me to sort it out.
I'm trying to get my Classic ASP application (works great on Server 2003/IIS 6) working on IIS 7.
I've done a zillion things recommended and finally got it actually pulling up the ASP front page that reads from a database.
But when I try to write to the database, I get errors. "Microsoft JET Database Engine error '80004005' Operation must use an updateable query."
Note: In the application pool for this classic ASP site I created an identity of "app_pool_casemodo" and then gave [website folders], [database folder], windows\temp, inetpub\temp, and windows\serviceprofiles\networkservice\AppData\Local\Temp all modify permissions for that user.
I installed Microsoft's Process Monitor and it is telling me there is an issue with a user account "app_pool_casemodo" having sufficient read/write permissions in relation with this registry key: HKLM\SOFTWARE\Wow6432Node\Microsoft\Jet\4.0\Engines. So I used regedit and browsed to that key and made sure that account had plenty of permissions.
Tried using DSN and tried using just file pointing ODBC string and both exhibit read but no write issue.
Image of process monitor screen attached.
Please help. I've been banging my head for many days on this stuff. Feeling like I'm super close to a solution.
The user IUSR_< MACHINENAME > has permission over the access file?
I am new to classic ASP. I would rather ask question than do hour of research to solve my problem.
I am accessing access database and getting the following error.
Microsoft OLE DB Provider for ODBC Drivers error '80004005'
[Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified
/default1.asp, line 30
The culprit line is this
Set MyConn = Server.CreateObject("ADODB.Connection")
MdbFilePath = Server.MapPath("c:\database\MyDatabase.mdb")
Well, I do not have Access installed but I copied the .mdb file to the specified folder, will it work that way? I am familiar with SQL Server, and that has to run in order to retrieve data from it.
It uses ADODB but I can't file the DLL. Can someone specify the DLL for me. What I have to do to get it working. Just registering it will work using regsvr32 my.dll?
I could not find a connection string (I usually use a connection string to connect to my SQL Server). Do I need one for Access database in this case?
Please help
It's been a few years for me, so this answer might be a little out of date. Also, since the Access db ends in .mdb, I'm assuming that it's a pre-2007 database.
Yes, just the file should work. Access does not need to run, it just needs to read the file. However, you may need certain components installed to talk to the Access database (used to be MDAC
- http://www.microsoft.com/download/en/details.aspx?id=1953, not 100% certain if it still is). MDAC contains the JET engine, which classic ASP uses to talk to Access files.
As for the connection string, this web site that provides some examples of access connection strings: http://connectionstrings.com/access
edit - adding more info
Just in case I'm not following the comments correctly, here's an example of how to connect to the Access database through Classic ASP:
Set MyConn = Server.CreateObject("ADODB.Connection")
MdbFilePath = "c:\database\MyDatabase.mdb" ''# Server.MapPath is not needed, since we are providing the whole path already
MyConn.Open "Provider=Microsoft.Jet.OLEDB.4.0; Data Source=" & MdbFilePath
When running the code above, do you receive the error still? Also, what's the set up you're running (IIS7, IIS6, 32bit, 64bit)?
I have a package that imports from a AS400 file to SQL. The package executes properly within Visual Studio, but fails when set up as a scheduled job. the error message is that my password is incorrect. I know that it is correct. I also setup a package configuration and this did not work. I have searched and tried many things. Could someone give me some assistance?
Your password is incorrect.
Seriously, you "know" that your password is correct? You know better than the code attempting to use your password? Does this seem likely to you?
Consider the possibility that you and SSIS may be referring to different passwords. Maybe the one you "know" is correct actually is, but the other one is not.
Possibly a stupid answer, but how are you connecting to the AS400? If it's using ODBC drivers, you'll need the AS400 drivers installed on both local (dev) and your SQL server box. They're notoriously picky about versions.
If memory serves me correctly, when you set up the ODBC connection using the AS400 driver software, I think you need to specify connection details as well and they get explicitly saved in the ODBC connection.
The support link above is correct. To boil it down to a simple answer. Password protect your SSIS package to save the credentials needed to connect to the AS400.
With the ODBC configuration: use a system DSN instead of user DSN, it will work!
Try to use odbc connection or try to redeploy the package on your SSIS Server.