Apps Standardized on Remote Views or SPT or CursorAdapters or Any

[stanlyn]

Hi,

Is it customary to standardize on one technology like remote views, spt, or cursoradapters and try to stay with it?

Does your apps use a specific technology 100% of the time? If not, do you try to make it 100%, or do you not care and use whatever is the easiest? The answers to this is important, because if you don't care and use whatever, then I can lighten up and take that approach while knowing I'm not alone.

So far, I have been trying to stay all cursoradapters as everyone says its the best and most flexible. While trying to keep it all as cursoradapters, I keep thinking of easier ways using remote views or SPT and keep resisting the urge to do them, which would make my app a mixed bag. The specs I've seen also suggests that.

Just wondering what is normal?

Thanks,
Stanley

 

[Mike Lewis]

Stanley,

Good to see you back here again - but not so good to hear about your terrible experiences last summer. From this distance, I don't think many of us realised how bad things were.

Anyhow, to try answer your question:

Is it customary to standardize on one technology like remote views, spt, or cursoradapters and try to stay with it?

That's certainly not my view. I tend to use SPT as my first choice, but I will happily use the other methods - including in the same application - where there are benefits in doing so.

As with all aspects of programming, there are pros and cons to each of the approaches.

I have been trying to stay all cursoradapters as everyone says its the best and most flexible

In this case, I wouldn't give too much weight to what "everyone" says. There is indeed a strong argument for using cursor adapters, but if you see advantages in using the other methods - or even if you just feel more comfortable doing so - then that's what you should do.

At least, that's my opinion. No doubt others will disagree.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[tomk3]

Hello,

good to see you back.
I agree with mike : choose the one you are comfortable with and if you do not have too many programmerrs in the project mix according to your needs.

We do as follows (MS-SQL)
small tables : RV read/write , for example base data like possible adresstypes (< 100)
data selection : RV read only with parameters from userfilter and maybe joins
insert/update/delete : RV with the unique key as filter (so max 1 record)
getting / checking a value : SPT
getting special filtered data : SPT

Most of it is encapsulated in functions / classes.

We use RVs because we open all on startup with NODATA and index them. Then in the program its like the usual "use dbf" with some requery/tableupdate. It reduced costs when years ago we migrated everything form dbf to SQL. For us it also makes grid constructiun in IDE easy and checking data is just use xxx - browse.

Regards
tom

 

[Chris Miller]

Agree with Mike, there are different levels. Once you built your architecture a general CA you programmed used as oCA = CreateObject("anytableca","mytable") can also replace a USE mytable, for example. Though I doubt you get happy with such a construct without more specific CAs, in the end after you did your work the usage of CAs could cover all simpler cases, too. That's what OOP is all about, designing the classes so their usage is a simple to you as possible. It should not matter much that instead of just having opened a table in a workare, the usage of a CA also creates an object instance of it in memory and has a bigger footprint. The CA can hide whatever is the table, a dbf or another database table.

Chriss

 

[stanlyn]

Hi all,

Looks like everyone agrees that we can mix it all up based on the need, especially with small groups of developers.

Thanks,
Stanley