>Here's my question - is there an overriding reason to code the data-connection class in either VB *or* VFP? This app will definitely have components of both languages anyway, so run-times, etc., are not an issue. Is VB (or VFP) more stable as an ADO-connection layer? Is VFP (or VB) quicker at the pure connection piece of it? Remember, this data conenction class is responsible for establishing a connection and returning a recordset - nothing else. No data-processing involved in this later.
>
>I am leaning toward VB because I have a hunch that the resulting object will be smaller than a similar VFP object; does anyone else have an informed opinion to add to the mix for me?
>

A couple of obvious arguments are that the VB object is going to be smaller; from a pragmatic POV, the constants are already defined for VB using ADO, and sample code in docs/texts tends to be written in VB, and later in the game if .NET is an issue, VB is slated to be a full player in the CLR, so it's reasonable to assume that it'll have less overhead when using .Net resources, since VFP will need to work through an Interop layer, so will incur at least some (unknown impact) additional overhead accessing .Net resources, including ADO+. Early binding should be part of VFP7, with it's IMPLEMENTS interface inheritance and new option of strong datatyping. The data connection service you describe doesn't rely on VFP's major strengths, so VB appears to be a better fit, both now, and later should the service migrate to the .Net environment.