I ran across something interesting (albeit of limited use) recently. We are considering integrating Maximizer CRM with our software, and I’ve been doing some proof-of-concept work along those lines. One thing about CRM software creators is they know they won’t be replacing your core line of business applications, so they make sure there are plenty of ways to integrate with those apps. Maximizer is no exception, and being around for quite a few years now, it includes some old-school (but new to me) integration techniques.
The first thing I wanted to do was import some Fox data into Maximizer. While older products often included native support for dbase and FoxPro 2.x tables, virtually no products supported Visual FoxPro natively, so I was surprised to see FoxPro 3.0 in the list. I use VFP 9.0, but I haven’t made use of any of the new database features added in versions 7.0 – 9.0. So, I gave it a try and it worked like a charm. “Wow, that was easy”, I thought, “I wish Microsoft products supported their own database this well.”
Well, it turns out, they used to. To my surprise, this all led me to the fact that DAO 3.5 had native support for Visual FoxPro tables. DAO (data access objects) was Microsoft’s data technology that preceded ado (ActiveX data objects) and was popular with access and VB developers at the time. It is now deprecated, but some access developers still favor it over newer technologies. It has been my assumption that Microsoft access got its name because it could “access” multiple databases in addition to its own jet database. It has done this by means of “ISAM filters” for other databases, including FoxPro. DAO 3.5 included a filter for Visual FoxPro.
Eventually, ado came along and superseded DAO as the recommended way to access data. The ISAM filters became part of the Microsoft jet 4.0 engine, but the FoxPro filters were no longer included in the package. WTF? Yet another slight against our beloved Fox? Perhaps, but also consider this: the ISAM filters suck. While I am sure they work fine for FoxPro 2.x data, the VFP filters are limited and give you read-only access to data. Compared to the FoxPro ODBC drivers, which give full read/write access as well as much improved performance, it became apparent that ODBC was the preferred way to access FoxPro data and I assume that’s why the ISAM filters were removed.
While I would never recommend DAO for new development, we often find ourselves working with older systems and technology. It’s interesting what you run across.
Resources:
- How to use Visual FoxPro tables in Visual Basic
- How to open a Visual FoxPro table for read/write
- Data access technologies road map
I know this is a little late, but wanted to mention that I devised a way to communicate with Maximizer 10 with VFP 9 via ODBC/SQL Passthrough. We have had pretty good success with the implementation. Not sure if you’re still involved with Max, but if you have any questions, let me know. wiley <no space> s AT hotmail dot com.
Steve, it looks like our Maximizer integration project is not going to happen, but if it comes back to life, I’ll definitely keep this in mind. Thanks.