Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations TouchToneTommy on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

CursorAdapter or not ?

Status
Not open for further replies.

FoxWing

Programmer
Dec 20, 2004
44
GB
I developed 2-tiers accouting system using Foxpro with VFP native tables.

Now, I'm thinking of extending it to talk to MSSQL server. I was planning to use SPT but then I came across a class called CursorAdapter.

My question is which one should i use for minimum work. CursorAdapter sounds promising but until i read the statement below from a VFP forum.

"CursorAdapters are great in theory, but seem to not be as solid as they should be. I'd strongly recommend SPT"

Until now, i haven't started anything yet as i'm still deciding which approach to choose.

My existing codes are all using SCAN..ENDSCAN, LOCATE and inline SQL statements. If so, which approach would u all recommend ?

Thanks
 
FoxWing said:
My question is which one should i use for minimum work

The answer (as it envariably ends up being) is, it depends. If you mean minimum work for right now, then I would say go with what you know. Nothing wrong with SPT (SQL Pass-Through), and there are plenty of advantages that it gives.

However, if you're looking at a system that may switch backends or utilize different data sources and needs something more scalable/extensible and object oriented... then the minimum work in the long run would probably be CursorAdapters.

They haven't caught on quite as much as I thought they would with the VFP Community as a whole. They are still shy from being the universal adapters that they were meant to be... hopefully MS will continue to improve upon them and those of us that have implemented them will reap more and more benefits as time wears on.

Myself? I use a mix depending on what I'm doing and what kind of future requirements I can envision based on the customers' goals. Plus, I have a penchant for messing around with whatever is new in VFP.

Having somewhat broached that subject, I notice that you say your accounting system uses VFP native tables (perhaps you meant free tables?)... so, quantifying my next statement with, I have only the limited information you've provided... I would say that the easiest, fastest, and most bug free way to go about most of this would be to replicate your database/table design(s) using a VFP Database containing remote views hooked up to the database backend. This would also allow you to further extend your program in the future to additional backends as well, with perhaps very little work and debugging on your part. Just a thought.

boyd.gif

 

FoxWing,

I pretty well agree with Craig. I tend to use a mixture of remote views and SQL pass-through (I will use RVs more in VFP 9.0 because they now support varchars). I haven't seen a pressing reason to go to cursoradapters, but am still keeping an open mind.

I think the stongest point in favour of cursoradapters is that they make it simpler to move to an N-tier architecuture. That's because they will allow you to move recordsets (or alternatively XML) between tiers, which is something you can't do easily with VFP-style cursors.

For me, RVs and SPT have the advantage of letting me work in a familiar way. But your situation will probably be different.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My sites:
Visual FoxPro (www.ml-consult.demon.co.uk)
Crystal Reports (www.ml-crystal.com)
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top