Yeah, I had heard that from Markus. As far as what I'm doing. You know: same old same old. I'm trying to divide my time between work and Kuk Sool. (I'm trying really hard to make it to 2nd degree in two years. And picking up some pretty cool stuff along the way, I might. Like how to use acupressure on someone's back to relieve pain.)

>Hey Travis - howzit goan? Guess you know I bolted Eagle.
>
>>First off, let's assume that you consider the conversion of an ADO recordset to a cursor and back to be too time-consuming. And let's face it, the only reason you need it is for display and reports.<
>
>I've already ruled that out. Way too time-consuming. We're dealing with tables with recordcounts in the hundreds of thousands.
>
>> Well, what if I told you I knew of a great ActiveX control out there that worked with ADO to display information? Do you remember the application that beat us this last year? They used a control called Janus GridEx 1.6 something. You can find it at www.componentsource.com. I'm telling you, it's really great. Prevents a lot of headaches on my end.<
>
>I'll check it out. At this point we are open to suggestions.
>
>>Anyway, most people simply deal with the connection and recordset objects. However, in theory (I haven't had time to test it yet), if you make proper use of the command and parameter objects, you could theoretically switch between back-ends simply by changing the connection string. (Assuming they're compatible with and have an OLE-DB provider.) Imagine creating "paramterized" recordsets by properly using the command and parameter objects. Since you're basically telling ADO to give you a recordset where this parameter is this value and so on, you don't have to worry about little changes in syntax. Pretty cool concept, huh?<
>
>Yep. It's a very real possibility, too. The app I'm working on is already being marketed to outside clients, and who knows what they'll want to use.
>
>>Also, from my own experience, it's much better to have client-side recordsets so that you can "persist" them or save them to disk.<
>
>I'm not so sure of the usefullness of that in this app. The two biggest concerns are 1) speed, 2) being able to dynamically see changes made by others without having to requery all the time, and 3) keeping the current navigation/order changing functionality. Okay, that's three, not two. But not five. Five is right out. Anyway the dynamic server-side cursor seems to fit the bill for at least this first part I'm working on.
>
>>Now as far as reports go, remember how great HTML is in displaying graphical information? Guess what? If you didn't already know, ADO 2.0, which ships with IE5 if I'm not mistaken, can save a recordset as an XML file. You can also create an ADO recordset based on XML. Imagine that. You can actually create a nice looking report without ever having to use the VFP report writer.
>>
>>You know, the list is endless for possibilities. Anyway, let me know what you think.<
>
>Hadn't even thought of the report angle, but then there's a whole team of folks just working on reports - not my AOR. But it's an idea to file away in the back of my head.
>
>So what's happening with you these days? Gonna try the beta exams?
>
>Cheers - Dan