Rsview SE and SQL

[wonderboutin 0]

I use Rsview SE with SQL. I want to connect with my database but I can't use a datalog model because, my database is not on the same format. Is not compatible. I want to connect whit my sql database in VBA. Can you help me ?

[Tech Fred 3]

With a SQL data base you could use an ODBC interface to see the data. Check out Kepware's ODBC Client Drviver (http://www.kepware.com/Spec_Sheets/ODBC_Client_Driver.html) RSViewSE can connect to it with no problem.

[wonderboutin 0]

Tanks! But I realy want to connect with VBA of Rsview I can connect with VBA from Excel but in VBA of Rsview, I have the error "User-defined type not defined" on the command "Dim connect As New ADODB.Connection.

[paulengr 44]

This indicates that VBA in RS-View is not linked to the ADODB library. You might have access to the older VB 4 commands (SQLOpen for instance). Otherwise if you want to use ADO, you have to do this yourself. Change the code to something like the following: dim myconnect, myrecordset, myname set myconnect = CreateObject("ADODB.Connection") set myrecordset = CreateObject("ADODB.Recordset") myconnect in this format is a variant. Since it will be simply a pointer to an OLE object, the only legal type is variant. This creates an OLE object (ADODB) and then links the namespace of the ADODB object into VBA's name space. Once you've done this, the usual stuff like myconnect.Execute will work fine. What is really happening is that internally, VBA will convert it's native call and data into OLE format, send it to the OLE object, and then handle the return in the normal way. You can use this exact same method to use almost any VB code as long as Windows can find the DLL to run it. That's the good news. The bad news is...welcome to OLE hell! The real nightmare here is three fold. First, far be it for Microsoft (or anybody else for that matter) to document virtually any of their libraries completely. There's no real way to simply "inspect" an object to determine what it's real interfaces are and even if you can, you will frequently find yourself running test after test poking at the OLE object to figure out how to make it work. The second problem is that any time you see a constant used (most network libraries for instance are full of them), you don't have the link to the VB library so you have to search around trying to find what the constant is (they are not defined within the OLE object). The third problem is that the basic libraries that are within the evil VBRun.dll library are licensed. If you have a full VB license, you can access them. Which means that every place you use them from VBA, you need a full VB license! And since anyone using VB is obviously using VB and not VBA, there isn't a problem, right? So you will have to search around for a long time trying to find alternative libraries to Microsoft's that don't charge you with similar outrageous license fees to do the simplest things such as TCP/IP communication....by the way, look for "Osisoft" if you are trying to do the latter. Your alternatives are to become a C++ programmer and to make your own interfaces that work with RS-View, become a VB programmer and make your own ActiveX (OCX) modules to work with RS-View, or realize that you are a mere mortal and learn to live within the confines of RS-View (or Citect or iFix or Cimplicity or...)