By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
428,659 Members | 940 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 428,659 IT Pros & Developers. It's quick & easy.

Problem using FoxPro OLE DB Connection

P: n/a

Greetings,

I am running IIS on W2kServer and am trying to use ASP with some
legacy X-Base tables. I cannot get the provider to connect.

Relevant code is:

strProvider = "Provider=vfpoledb;Data Source=C:\DB2\DDMS\"

set objConn = server.createobject("ADODB.Connection")

objConn.Open strProvider
This style works fine with Access tables, but I get the following
error with the vfpeledb connection attempt:

An exception of type "ADODB.Connection: Provider cannot be found. It
may not be properly installed" was not handled.

I have installed the Visual FoxPro v8 drivers, and have set the
metadata in the global.asa file as follows: (watch the word wrap)

<!--METADATA TYPE="TypeLib" NAME="Microsoft ActiveX Data Objects 2.7
Library" UUID="{EF53050B-882E-4776-B643-EDA472E8E3F2}"
VERSION="2.7"-->

<!--METADATA TYPE="TypeLib" NAME="Microsoft OLE DB Provider for Visual
FoxPro 7.0 Type Library" UUID="{50BAEECA-ED25-11D2-B97B-000000000000}"
VERSION="1.0"-->

Then ASP complains that it cannot find the metadata:

Active Server Pages, ASP 0223 (0x80004005)
METADATA tag contains a Type Library specification that does not match
any Registry entry.

Registry entries ARE present for the v7 library, but not the v8 - I
assume this is normal. Reinstallation changed nothing. The dll is
present in the proper directory, and all registry entries point to it.

References in InterDev v6 show up and I can open the tables fines
within the IDE, but ASP refuses to acknowledge their existance.

Any ideas?
Dr. Know
Jul 22 '05 #1
Share this Question
Share on Google+
9 Replies


P: n/a
Dr. Know wrote:
I am running IIS on W2kServer and am trying to use ASP with some
legacy X-Base tables. I cannot get the provider to connect.
...
strProvider = "Provider=vfpoledb;Data Source=C:\DB2\DDMS\"
...
I have installed the Visual FoxPro v8 drivers, and have set the
metadata in the global.asa file as follows: (watch the word wrap)


Have you tried using a .udl file to generate a connection string?

--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.
Jul 22 '05 #2

P: n/a
Dave Anderson said:
Dr. Know wrote:
I am running IIS on W2kServer and am trying to use ASP with some
legacy X-Base tables. I cannot get the provider to connect.
...
strProvider = "Provider=vfpoledb;Data Source=C:\DB2\DDMS\"
...
I have installed the Visual FoxPro v8 drivers, and have set the
metadata in the global.asa file as follows: (watch the word wrap)


Have you tried using a .udl file to generate a connection string?


No, we are trying to use the OLE DB provider, not the old ODBC
connection method. Something about obsolete, dysfunctional drivers,
improper handling of non-string fields, and multiple thread contention
issues...

Of course, this is all new to me, and I could be wrong...
Dr. Know
Jul 22 '05 #3

P: n/a
Dr. Know wrote:
Dave Anderson said:
Dr. Know wrote:
I am running IIS on W2kServer and am trying to use ASP with some
legacy X-Base tables. I cannot get the provider to connect.
...
strProvider = "Provider=vfpoledb;Data Source=C:\DB2\DDMS\"
...
I have installed the Visual FoxPro v8 drivers, and have set the
metadata in the global.asa file as follows: (watch the word wrap)


Have you tried using a .udl file to generate a connection string?


No, we are trying to use the OLE DB provider, not the old ODBC
connection method. Something about obsolete, dysfunctional drivers,
improper handling of non-string fields, and multiple thread contention
issues...

Of course, this is all new to me, and I could be wrong...

You are. A UDL file can use either ODBC or OLE DB. You have two options:
A. Go to www.able-consulting.com/ado_conn.htm and look up the correct
connection string for foxpro (which I've never used so I can't advise you)
B. Try using a UDL file to generate a connection string:
1. Right-click your desktop and choose New| Text File
2. rename the file test.udl
3. double-click it to start the wizard
4. On the first tab, choose the foxpro provider if it's there
5. go through the remaining steps to point it at your database file
6. test the connection
7. if the test is successful, close the wizard and open the file in
Notepad. You will see the connection string in plain text

HTH,
Bob Barrows
--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"
Jul 22 '05 #4

P: n/a
Bob Barrows [MVP] said:
Dr. Know wrote:

No, we are trying to use the OLE DB provider, not the old ODBC
connection method. Something about obsolete, dysfunctional drivers,
improper handling of non-string fields, and multiple thread contention
issues...

Of course, this is all new to me, and I could be wrong...

You are. A UDL file can use either ODBC or OLE DB. You have two options:
A. Go to www.able-consulting.com/ado_conn.htm and look up the correct
connection string for foxpro (which I've never used so I can't advise you)
B. Try using a UDL file to generate a connection string:


OK - I read the previous answer incorrectly. I thought he meant to
use a dsn file to open the DB through ODBC...

But nevertheless - it still doesn't work.

The wizard creates this connection string:
(which differs little from my original string)

Provider=VFPOLEDB.1;Data Source=C:\DB2\DDMS;Password="";Collating
Sequence=MACHINE

It tests OK in the wizard, but refuses to work in ASP - although it
and my original string work in VBA. Alternate DB formats, such as
MDB, also work fine...

I am beginning to think it's a bug... uhh... feature... :-|

And I'm not kidding about the dysfunctional VFP drivers & improper
handling of non-string fields, read this for a taste of the bizarre:

http://support.microsoft.com/default...b;en-us;321631

This is why we went to the new v8.0c drivers...

Thanks,

Greg
Dr. Know
Jul 22 '05 #5

P: n/a
Dr. Know wrote:
The wizard creates this connection string:
(which differs little from my original string)

Provider=VFPOLEDB.1;Data Source=C:\DB2\DDMS;Password="";Collating
Sequence=MACHINE

It tests OK in the wizard, but refuses to work in ASP - although it
and my original string work in VBA. Alternate DB formats, such as
MDB, also work fine...


We had a similar problem with Oracle drivers above 9i, and the solution
involved propagating permissions in the Oracle directory structure. The
problem in that case was that IIS runs under a system account whose
permissions are either not set up correctly by the Oracle installation, or
were altogether nonexistent.

If I had to guess at this point, I'd say you have a file permission problem.

--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.
Jul 22 '05 #6

P: n/a
Dr. Know wrote:

But nevertheless - it still doesn't work.

Please try to describe your symptoms without using the words "doesn't
work".

Is it the same error? An exception of type "ADODB.Connection: Provider cannot be found. It
may not be properly installed" was not handled.


If so, you need to realize that the ASP application is running under a
different user account than the one being used when you tested your UDL
file. The IUSE_machinename account needs to be granted sufficient
permissions to allow you to use this provider. Unfortunately, never having
used foxpro, I'm not really sure what those permissions have to be (I
suspect Registry keys are involved). Please try a foxpro group for help.

Here are some search results for you to investigate:
http://support.microsoft.com/default...b;en-us;278604
http://support.microsoft.com/default...b;en-us;883842 - similar
error for different database, which does talk about permissions

http://groups-beta.google.com/group/...c2fb9bf13d4f61

http://vfpdev.narod.ru/docs/spcall_e.html#oledbsolve - scroll down to the
bottom

http://www.google.com/search?sourcei...e+found%22+ASP

Bob Barrows

--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"
Jul 22 '05 #7

P: n/a
Bob Barrows [MVP] said:
Dr. Know wrote:

But nevertheless - it still doesn't work.
Please try to describe your symptoms without using the words "doesn't
work".
Is it the same error?
An exception of type "ADODB.Connection: Provider cannot be found. It
may not be properly installed" was not handled.


Yes, Same symptom, Same error - I suppose my frustration is showing...
If so, you need to realize that the ASP application is running under a
different user account than the one being used when you tested your UDL
file. The IUSE_machinename account needs to be granted sufficient
permissions to allow you to use this provider. Unfortunately, never having
used foxpro, I'm not really sure what those permissions have to be (I
suspect Registry keys are involved). Please try a foxpro group for help.
I did not take that into account - and (improperly?) assumed that all
OLE DB providers were allowed the same security through MSDAC.

I actually did do a search at MS for the error string, but didn't come
up with these particular matches.
Here are some search results for you to investigate:
http://support.microsoft.com/default...b;en-us;278604
http://support.microsoft.com/default...b;en-us;883842 - similar
error for different database, which does talk about permissions

http://groups-beta.google.com/group/...c2fb9bf13d4f61

http://vfpdev.narod.ru/docs/spcall_e.html#oledbsolve - scroll down to the
bottom

http://www.google.com/search?sourcei...e+found%22+ASP

Bob Barrows


Thanks, Bob, for the research and info - you have gone out of your way
to help with this.

I'm not certain we'll EVER resolve this behaviour - seeing that it
works properly under VBA and VB, but not VBScript. We don't actually
USE FoxPro - we just have to deal with it's legacy remains. I'm of a
mind at this point to just rely on a service written in C++ or a COM
object to handle the postings to the X-base DBF. The ASP page
actually writes the user info into an MDB or SQL Server DB at first,
but after some processing, it is then posted into a legacy DB system.
I suppose this could be (better) handled with a daemon.

I'll look into the permissions aspect, but I don't know how I would
change the behaviours for different DLL's individually. I HAVE
re-registered the DLL and checked the registry entries manually - that
was my first response to the error.

Thanks again,

Greg
Dr. Know
Jul 22 '05 #8

P: n/a

SOLUTION BELOW

Dr. Know said:
... but I get the following
error with the vfpeledb connection attempt:

An exception of type "ADODB.Connection: Provider cannot be found. It
may not be properly installed" was not handled.

I have installed the Visual FoxPro v8 drivers, and have set the
metadata in the global.asa file as follows: (watch the word wrap) ...... Registry entries ARE present for the v7 library, but not the v8 - I
assume this is normal. Reinstallation changed nothing. The dll is
present in the proper directory, and all registry entries point to it.

References in InterDev v6 show up and I can open the tables fines
within the IDE, but ASP refuses to acknowledge their existance.


The solution to this problem has been de-mystified!
Thanks to all who helped out with this aggrevating problem.

It seems that MS is adding some improper registry entries with the new
VFPOLEDB.DLL installation - otherwise known as Visual FoxPro v8
Service Pack 1.

I uninstalled the original install with the MS installer - after
having saved copies of the VFPOLEDB.DLL file and the help.chm files
that were installed.

After removal, I replaced the copied DLL into it's original location
and registered it manually. Viola! It works fine...
Manually re-registering the DLL does not work - you have to uninstall
it with the "remove programs" installer first!

Thanks, Bill! Another day shot to @#$.

And Thanks to MVP Bob who pointed me to the Russian web site that
oriented me towards this solution.

Greg


Dr. Know
Jul 22 '05 #9

P: n/a

Hi Dave Anderson,

I happened to see your post re an OLEDB-Oracle error that you mentioned in
one of your posts.

I summarise the issue that I have as follows

1) I wrote a VB component, which connects to an Oracle DB and does some data
retrieval and updates
2) This component is instantiated in ASP page and when the ASP page runs it
gives the following error, "Error 3706: Provider cannot be found. It may not
be properly installed."
3) I am using cnDB.Open "Provider=OraOLEDB.Oracle;Data Source=111;User
Id=111;Password=111;" and i have checked that the VB COM works when called
within a VB program
4) considering that VB COM connects to the Oracle DB successfully when
instantiated from VB, I am not sure why it does not work from ASP.
FYI, I'm running Oracle 9.2, MDAC 2.8, WInXP service pack 1.; uisng local
IIS (developer workstation)
Would really appreciate any help.
Thanks
Rajy
"Dave Anderson" wrote:
Dr. Know wrote:
The wizard creates this connection string:
(which differs little from my original string)

Provider=VFPOLEDB.1;Data Source=C:\DB2\DDMS;Password="";Collating
Sequence=MACHINE

It tests OK in the wizard, but refuses to work in ASP - although it
and my original string work in VBA. Alternate DB formats, such as
MDB, also work fine...


We had a similar problem with Oracle drivers above 9i, and the solution
involved propagating permissions in the Oracle directory structure. The
problem in that case was that IIS runs under a system account whose
permissions are either not set up correctly by the Oracle installation, or
were altogether nonexistent.

If I had to guess at this point, I'd say you have a file permission problem.

--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

Jul 22 '05 #10

This discussion thread is closed

Replies have been disabled for this discussion.