QBasic and Database access (Sql Server) 2

[bigmann]

I have a customer that wants to access our SQL Server 2000 database over TCP/IP with QBasic. He has the QBASIC program enabled to access the COM port and dial his ISP to connect to the internet. Is there even a way to access an SQL Server with QBasic. He mainly wants to do Record inserts and reads. I know the first thing to run across you mind is, "Why would you want to use QBasic to do this???" Well he is trying to use a DOS-based board to automatically update status with a cost-effective solution...and putting a full-fledged PC at each location is not feasible. So if you have any other suggestions about how to do this...I am open...He is using a 386 board with 4MB RAM and DOS 6.22

Would C++ be able to do this?

Thanks,
Bigmann

 

[qbasicking]

I don't know about about Qbasic, but yes, I am pretty sure that C could do this, I believe that Microsoft mainly uses C and I've seen Microsoft software that could do this. Put this post in the C++ forum

 

[dilettante]

You have to remember that in terms of networking, QBasic is even more primitive than DOS.

At least DOS has standard networking support available, including TCP/IP. The problem is finding the toolkit to gave you access to it at this late date.

If you need TCP/IP access by a QBasic program you may have to go with some 3rd party TCP/IP stack and API. My attempts to get info on using Microsoft's TCP/IP for DOS from a QBasic program have hit a dead wall. More so here than anywhere else I have searched and asked.

But lets say you find a way to open a TCP socket from a QBasic (or even a DOS C) program.

I'm not sure such a low-level connection is accepted by SQL Server 2000. You have a whole lot more work to do to emulate ADO or ODBC running over the TCP port.

Instead, I'd build a simple database protocol from scratch. Something like a series of messages that go OUT from your QB program with a field to say "get" and "put", a field for the table name, and follow this by data fields. Dream up something similar for messages to come IN to your QB program.

Then write a Visual Basic program on a Windows machine that will listen for incoming TCP connections, accept them, and act on them.

The VB program can easily connect to the database using ADO.

The DOS/QB machines become "terminals" or "clients" to this middle-tier VB program. The VB program becomes an "adapter" of sorts for you.


This "adapter" approach isn't necessary if you can find something that can do ADO or ODBC out of a DOS program. DOS being so "moldy" now though, it might be tough to locate any decent tools for it anyplace.

It is hard to picture any single-board computer based on a 386 that has an ethernet port. This type of hardware is always premium-priced because of its low sales volume. Seems like for a few nickels more you could find something similar with at least a mid-ranged Pentium or Cyrix processor (say, 133Mhx range) and a lot more RAM. Then you could use an embedded NT product or for that matter perhaps even Win9x in non-GUI mode. Oh well, he probably already has the hardware though, huh?

The trick in getting an old DOS development toolset to work directly though is going to be the database connection itself. Even somebody's fancy-pants C++ for DOS (does such even EXIST?) is unlikely to "know" how to talk to a recent database product.

 

[Guest_imported]

Pretty Sure C++ could do it?

Well, it can, sort of. These functions are part of the Visual C++ development headers, but Visual C++ will not run on DOS. Most SQL Functions are in the Windows API.

 

[Guest_imported]

Yes C++ for DOS exists. In fact, Borland was up to C++ 3.0 for DOS by 1989. Neat.

 

[logiclrd]

Heh. SQL is not an API, it is a protocol. The Windows API for SQL is simply a Microsoft-ism. Any SQL-capable server will accept queries in text form by some means or another. Here is a primitive example of an SQL statement:
[tt]
SELECT PhoneNumber FROM PhoneBookTable WHERE LastName = "Smith"
[/tt]
As for TCP from QB, it is basically not worth trying. There are timing issues that must be handled continuously in the background to maintain a PPP connection over dialup. It is possible, however, that a terminal server could be used. In this case, the QuickBASIC program would talk to a server in much the way that a terminal program communicates with a BBS -- a plain text link. An account could be created on a Unix server that would, upon successful login, allow essentially direct access to the SQL server, and the QuickBASIC program could then issue SQL statements through the COM port. This would require substantial setup on the server side, but it would be just one time, of course, not once for every client machine.

As I mentioned earlier, I believe maintaining a PPP connection in the background with active TCP connections inside a QuickBASIC program with an active user interface is, while not impossible, somewhat of a lost cause. It would require more effort than is really worth for such a project at this point. While a packet driver could do the trick, I still think it's easier to let a terminal server handle the input.

Note that Unix would not be required: a Visual Basic program (as suggested earlier) could be used to accept incoming modem connections and relay the SQL statements to the server. This would still not require TCP connections from a QB program. I believe this route would be preferable.

If not all client machines are within local calling range of the server, it may be possible to find a local ISP that will allow such terminal server access. At the very least, a telnet command could be issued through the modem link by the QuickBASIC program.

Anyway, this is all based on speculation of information not available regarding the situation.