VB3 & SQL SERVER 2K

[Richard T. Edwards]

Be afraid, be very afraid<G!>

Seriously, though, VB3???????????? Actually, I don't think you can. When you
use createboject against "ADODB.Connection" what happens?

"Chang Cocho" <chan...@hotmail.com> wrote in message
news:#6g5v4ofCHA.2436@tkmsftngp10...
> I need to connect a VB3 app to a SQL server 2K database
>
> My box is a WinXP pro!!
>
>
> Any Ideas????
>
>

[Chang Cocho]

[Lazy Lurker]

Um... learn VB6 or .Net? Use Access? You really are fighting an uphill
battle with this one!

Hmmm... VB3 was pre-ADO (and 16 bit), so it probably doesn't support
ADO. That leaves the ODBC API or DAO. Not wanting to dust off a ton of
old notes on the API, I'd say stick with DAO - if 16 bit DAO can connect
to a SQL 2k database. There is an absolute ton of old information on VB
and DAO on the net - try sites like www.codehound.com/vb, or just do a
search on Google.

Good luck!

LL

[david epsom dot com dot au]

I'm gonna guess here that it is already a SQL 6.x application,
using ODBC. In which case you will need to have 16 bit
ODBC installed on your XP box. It will co-exist happily
with 32 bit ODBC. And if you're lucky and have a full
install image for the VB3 app, it will probably install all the
16 bit ODBC system that you need. Then you will have to
try to connect to SS2K using the old SS6.x odbc drivers
(never tried that). If it fails, you're gonna be looking for
3rd party 16 bit SS2K drivers..... (never did that either).

Or if you are working from source code, if it only uses
late bound dao objects, you just replace them with dao3.6
This is a pretty unlikely scenario - more likely you would
need a complete rebuild.

(david)

"Chang Cocho" <chan...@hotmail.com> wrote in message
news:#6g5v4ofCHA.2436@tkmsftngp10...

[Gary]

Gary wrote:

> Ouch. What fun.
> VB's pure 16 bit. SQL Server's pure 32 bit. So you've got a huge problem
> right away.
> Still, there are a few things you can do.
>
> 1. Depending on the data types involved, you have a small chance of
> getting the old SQL 6.5 16 bit drivers to work, via DAO. A very, very,
> very, small chance. Still, I have seen it work, with a bit of manual
> fine tuning.
>
> 2. Bring in an intermediate level to handle the data access for you.
> This could take many forms, depending on how much data you need to read,
> and what sort of response time you need. A simple example would be a VB6
> app which uses ADO to access the SQL Server database, which you could
> send SQL statements to via DDE, and receive the results (possibly as a
> delimited string) through the same approach.
> A more complex method would involve creating a new C++ DLL that VB3
> could use, which would apply thunking to handle the 16 - 32 bit problem.
>
> 3. I'm guessing that the powers-that-be have just decided to upgradee
> your SQL Server from 6.x to 2000. Am I right? If so, the problem SHOULD
> be able to be put back into their laps, because they didn't do enough
> research on the impact the upgrade would have on existing systems. This
> argument gives you enough leeway (if you're a good negotiator) to get
> the re-write of the VB3 app underway.
>
> 4. See if the powers-that-be are prepared to bring (back?)in a SQL 6.5
> server. A small one, with a 5-user licence would probably do. There are
> various methods that can be set up in SQL 2000 to replicate the data
> that you need from the 2k server to the 6.5 server. Then, you can carry
> on happily using VB3, without a re-write, using the SQL 6 ODBC drivers.
> The only extra work to be done is the setting up of the duplication of
> the data (DTS, triggers, etc)
>
> 5. Use a different method to access the data, other than ODBC/DAO. A
> masochist I know had some success accessing a SQL 2k database via
> Winsock and named pipes, but I suspect the 'how?' would turn into a 500
> page document. It might be worth looking around for other data access
> libraries. I haven't tried it, but the BDE that comes with Delphi might
> offer something, particularly if you look at a slightly older version.
>
> 6. Write your own drivers. Not an ideal option, but it's an option.
> Probably the worst of the lot.
>
> Regards,
>
> Gary
>
Oh, to add to point 2, one other thing that will probably be the easiest
of the lot - you SHOULD be able to link the SQL 2k tables to an Access
97 database, which you SHOULD then be able to read with the old Access
ODBC drivers, so Access will do the translation for you. In theory,
anyway. I don't have the right setup with me to test at the moment,
unfortunately.

Regards,

Gary

--

gpmusto...@hotmail.com
remove your hat to reply via email, although I read the newsgroups more
frequently than I check this account.

[Tore]

Do you have access to source code? If the application is important, it may
be about time to upgrade it...

If not, you could try setting up a 16-bit ODBC client. I don't recall if
RDO was available with VB3 (I don't think it was). If not, create an Access
database with links to the SQL Server tables ("attach" the tables in
Access/Jet 2.0 lingo), use DAO to access the Jet 2.0 database (your
intermediary), and specify SQL_PASSTHROUGH.

HTH,
Tore.

"Chang Cocho" <chan...@hotmail.com> wrote in message
news:#6g5v4ofCHA.2436@tkmsftngp10...

[glyn.ro...@gmail.com]

I know it's a bit late and you've moved on but this may help other people who are similarly stuck in the past.

If you look in the VB3 Help under the OPENDATABASE function you will see that you can connect to a SQL server database using ODBC.

You can even connect to a 64-bit SQL Server 2016 database using this method along with any other ODBC compliant database.
While the other advice to move the program to an updated language is the obvious answer - it is possible to work with VB3 and SQL server.

You can't use ADO with VB3 however but you are stuck with DAO.

I am in a similar position with a number of customers using applications written in VB3 and using ms-access V2 which I'd like to migrate to SQL server.
I'm choosing to update the programming language mostly because 16-bit apps won't run on 64-bit Windows.
However the VB3 apps DO run quite OK on windows 7/8/87/1/10 32-bit versions with no tricky workarounds required.

If the apps are not that large it shouldn't be too hard to migrate them to VB6 and use SQL server but I have VB3 apps with around 1,000,000 lines of code which pushes them to their absolute memory limit but they still work. tried to convert these to VB6 using my own VB6 conversion wizard on servral occassion but given up because the number of errors that you need to fix before the program will even run at all is so large.
Unfortunately you only find out about these errors one at a time using run, identify next error, fix error, run, identify next error, fix error, run and so on.

I have a number of customers running these VB3 apps on 64-bit Windows (even in 2017) by using a VirtualBox or VMWare virtual machine running a 32-bit version of the same Version of Windows as the host machine.
In some cases they've even been able to use the same product key for both the virtual and physical machine - which may not be totally kosher but since there is only one computer and one user involved I doubt that Microsoft would be too concerned.

anyway - to get access to a SQL server database from VB3 ...

Create an ODBC entry called MyDatabase which points to a SQL server database then run this code (or similar) in your VB3 application.

You can see that you CAN access a SQL server database from VB3 - not only that but the database I accessed was running in a 64-bit SQL server instance on a 64-bit windows 10 PC

Sub Main ()

Dim dBase As Database, rsWork As Dynaset, Cnt As Integer

Set dBase = OpenDatabase("MyDatabase", False, False, "ODBC; DSN=MyDatabase;UID=username; PWD=password")
Set rsWork = dBase.CreateDynaset("Select * from customers")
rsWork.MoveFirst
For Cnt = 1 To 10
MsgBox CStr(Cnt) & ":" & rsWork("Name")
rsWork.MoveNext
Next Cnt
rsWork.Close
dBase.Close
End
End Sub