ADODB Custom Wrapper?

We have a VB.NET project with a reference to ADO 2.6

When I open it on my machine, I get the following build error: "The referenced component 'ADODB' has an updated custom wrapper available."

When I double click on it, I get the following dialog appear:
http://homepages.rya-online.net/simonm/images/error.jpg

If I click 'No', for every object declared from the ADODB library, I get a build error as follows: "Reference required to assembly 'ADODB' containing the type 'ADODB.Connection'. Add one to your project."

If I click 'Yes', everything is fine on my machine but not on everyone elses machine. They get build errors telling them that the wrapper needs to be defined. The only way to get it to work on their machines is for them to delete the ADODB reference and re add it. Then on my machine, I am back to square one. :mad:

Any ideas anyone? :sick:

It sounds like you have different versions of ADODB on the different machines. One kind of hack way to work arround it is for you to copy the wrapper from another machine in to your bin folder and then reference the wrapper file directly by browsing to it. That has worked for me in the past when dealing with a similiar issue related to different versions of Office. The file in question will have Interop in the title.

I know that ADO.NET requires MDAC (Microsoft Data Access Components). I don't know for sure, but I'd guess that using ADO in a .NET app probably requires the same. I've seen a few articles that mention both ADODB and MDAC. I'd suggest getting the latest version of MDAC (2.8 SP1) and installing it on all machines.

I have that issue in a project too but I found out its from creating a project with a reference to a older version of mdac
and opening the project on a different system with a newer mdac version.

Dump ADODB.... completely..... Use ADO.NET..... which is about as close to "classic" ADO as VB.NET is to VB Classic.

Your problems stem from trying to use a COM component in .NET which isn't 100% fool proof.

My recommendation, read up on using DataReaders, DataSets and DataTables.... convert now & early... it will save you a lot of grief later in development.

Tg

I should be able to since my main project has not had the db schema completely developed yet and I only had the
reference to ADODB without any code yet. :D I need to desperately learn ADO.NET. That is my next priority. :)

I agree that ADO needs to go if at all possible. ADO.NET is easy to use and cutting the VB6 apron strings should be done ASAP. No sweat for those with flashy (figuratively and literally) avatars. :)

I new I would get some flack by posting that. :D

Anyone care to teach us the basics? :)

Whats a ...
Dataset?
DataReader?
DataAdapter?

Etc. as compared to ADODB.

The DataSet is a little database held locally. It contains DataTables and, optionally DataRelations. I think those names speak for themselves. The DataSet allows you to store data and operate on it disconnected from the original source.

The DataReader provides read-only, forward-only access to the result set of a query. It allows you to read data from that result set one row at a time from beginning to end. The DataReader is more efficient at retrieving data and is a good choice when data is simply going to be displayed or used, rather than edited and posted back.

The DataAdapter is the link between the DataSet (or an individual DataTable) and the database. It allows you to retrieve and post back data in a batch fashion. It is less efficient than the DataReader at reading data but provides other functionality like filling a DataTable, including schema, with one line of code. It also allows all changes to a table, including deletions, insertions and updates, to be committed to the database in a batch with one line of code (once all the appropriate SQL commands have been written, of course).

So basically all the data flows through the DataSet then depending on your needs you can use either the DataReader or Adapter
to read or manipulate the data. :thumb:

How about the connection object?

Quote:

---

Originally Posted by RobDog888

So basically all the data flows through the DataSet then depending on your needs you can use either the DataReader or Adapter
to read or manipulate the data. :thumb:

How about the connection object?

---

Not so. The DataSet is a convenient way to store data. The DataReader will allow you to retrieve data and you can do with it what you will. You can put it in a DataTable if you want but you don't have to. The DataAdapter retrieves the data and places it into a DataTable for you, then it will commit any changes to that DataTable back to the database for you also.

The Connection knows all the details about the database you are connectiong to through its ConnectionString property. Both DataReaders and DataAdapters use Command objects to determine how they should interact with the database. A Command is basically an SQL statement and Connection object.

Ok, I know Command Objects from ADODB and it sounds like they are the same.
So then all the dataobjects are independant of each other depending on what you want to do?

Sorry for hijacking the thread, simonm.

A Connection encapsulates a data source.
A Command has a Connection and some SQL code.
Calling ExecuteReader on a Command returns a DataReader.
A DataAdapter has up to four Commands.
A DataAdapter fills and updates a DataTable or DataSet.
A DataSet can contain multiple DataTables.
A DataView provides filtering and sorting for a DataTable.

Man, why did they have to go and complicate things? :( I'm sure its because of improvements but :confused:

I am using ADO.NET where I can but unfortunately, I have to reference a few vb6 DLL's that use ADODB as well because we haven't migrated everything yet.

Quote:

---

Originally Posted by simonm

I am using ADO.NET where I can but unfortunately, I have to reference a few vb6 DLL's that use ADODB as well because we haven't migrated everything yet.

---

Oh... you're still here? :) Let me combine two of my previous posts to crystalise my point of view on this matter. Use ADO.NET whenever and wherever possible, as you are. If you must use ADO for compatibility, I would suggest upgrading all machines to the latest MDAC version if possible. It is possible to create an installation requirement for a particular version of MDAC, and also to include the required MDAC version as part of your setup.

When I try to install the latest version of MDAC, I get the message "The setup does not support installing on this operating system". Incidentally, my operating system is Windows XP professional.

:(

The download page for MDAC 2.8 SP1 (version 2.81) says

Quote:

---

This redistributable installer for the MDAC 2.8 SP1 release installs the same Data Access components as Microsoft Windows XP SP2.

Supported Operating Systems: Windows 2000; Windows 98; Windows ME; Windows NT

---

The download page for MDAC 2.8 (version 2.80) says

Quote:

---

This redistributable installer for the MDAC 2.8 release installs the same Data Access components as Microsoft Windows Server 2003.

Supported Operating Systems: Windows 2000; Windows 98; Windows ME; Windows NT; Windows XP

---

Are you confused? I am. It sounds like WinXPSP2 already has MDAC 2.81 installed, but Win2003Server has the older MDAC 2.80. Are all your machines running XPSP2?

Well, there you have it. All our machines have XP service pack 2 and yet my ADO2.6 is incompatible with everyone elses! :mad:

Have other machines perhaps had VB6 installed that yours hasn't, which may have installed an older version of ADO or something like that? You haven't waved any cursed chickens' feet around have you? :) Something's going on and I insist on knowing the hell it is, damn it!

All our machines have both VB6 and VB.NET 2003.

What about the chickens' feet? :confused:

Did you run the Component Checker on the systems? It will tell you the version of MDAC on the system. If you dont have it,
its a free download from MS.

I ran the component checker and all our machines have an identical version of MDAC: 2.1 SP1 ON Windows XP SP2...

2.1? XP SP-2 comes with MDAC 2.8. You need to determine if the systems all have 2.8 if that what you
compiled your program on.

Yes, yes. We all have precisely the same version.