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 wOOdy-Soft on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Database Theory questions (Part 2) 2

Status
Not open for further replies.

Scott24x7

Programmer
Jul 12, 2001
2,828
JP
I started a new thread, because the other one got LONG...
To continue this time, than, is it safe to assume, that if I stick with my "Free Table" structure that I have now, that I would stick with a "Scatter/Gather" methodology, and also using "SCTRVARS" "SHOWGETS" routines that I have to control refresh/display of data, based on form state? (States being, View, Edit, Add).
Thanks,
-Scott
 
Begin Rant:


OK, I read the other thread, and have held my tounge but this is getting beyond bad advice into the realm of total stupidity.

Scatter Gather with the limited exception of Scatter Name is dead. There is absolutly no reason to use it. Use either table or row buffering, I would suggest row buffering because you have more control.

Use the form designer, textboxes and bind the textboxes to your tables or better yet views. (Oh, I forgot the other so called experts told you not to use DBC's for reasons beyond my comprehension). Yes there are a few minor dificulties with using a dbc but the long field names, referencial integrity, views and other benefits far outweight them.

As to using a show gets, the last time I coded one of those was in the last 2.6 application I wrote. If one of my junior programmers today showed me some code with a show gets in it, his next experience would be the door hitting him on his way out of it.

If you truly want to program using free tables, scatter gather and show gets, you might as well be using FPW 2.6. Why have all the additional baggage of an advanced 32 bit progam (VFP) if you are not going to use it.

End Rant:

Seriously you are getting some extremely bad advice in this forum. I would highly recommend you visit a site that sells most of the best books available on using VFP properly, buy and read some of them before continue onward.

Before anyone asks, I have no relationship to Henzenwerke except as a customer and meeting some of the authors at various Devcons.
 
fluteplr,

I agree with you on the part that the use of DBC is made somewhat as a 'no go'.

The reason is often that people are used to using free tables and do not (I guess) have the time to learn the new features of a DBC.
The DBC has not been invented for nothing.
I my app I use DBC's and table buffering and it works fine for me. I did not have to learn many things to accomplish that.
In my own experience, I learned that to put in the time to learn how things work, often pays itself back.
The same goes for using OOP in VFP. I often see (no offense intended), a VB type of approach to VFP, as where programmers use forms to start an application. With this I mean that I personally do not find the forms that interesting as where the logic and the ease of programming behind it all, is much more interesting and important (to me at least).
Using OOP enables you to make consistent forms that have the same look and feel throughout your application. Once you establish that in your baseclasses, programming other maintenance forms (or other types) can be made so easy, that you will have made a maintenance form within minutes by only subclassing and setting properties (the logic is already in the baseclasses).

The same goes for using Free tables vs DBC.

I would like to advice TheManiac to invest some time to learn more about the use of DBC's, views, table buffering and transactions.
They can be used very easily once you get the hang of it.

Forget about SCATTER and GATHER MEMVAR (at least for the moment), use things like table buffering/views, tableupdate(), tablerevert() etc.

You can all find it back in the MSDN/VFP online library/VFP programmers guide at the Microsoft site.

Good luck,

HTH,
Weedz (Wietze Veld)
My private project:CrownBase source code can be downloaded !!
 
fluteplr

The issue of .dbcs has been the subject of a number of threads, and produced various shades of opinion as to their merits.

Opinion is the keyword, and opinions are not facts.

Some of these opinions are clearly counter to your own but Seriously you are getting some extremely bad advice in this forum. seems to be an extreme statement.

The facts of the matter are that there is very little a .dbc can provide that can't be achieved through the use of free tables.

In Scott's situation, if I read it correctly, he has no actual need to go .dbc, and some of the opinions expressed therefore have been effectively, 'if it ain't broke, don't mend it'.

(Oh, I forgot the other so called experts told you not to use DBC's for reasons beyond my comprehension)

Anyone considering themselves to be an expert on VFP is probably verging on lunacy and deserves to hear the rustle of white coats in the corridor.

What we have in this forum is the freedom to give of our experiences to others. If it was factually correct that the advice given was improper or incorrect, then no one would be concerned about the claims you have made.

As that is not the case, then deriding those who have expressed ideas that don't fit in with your own, is disengenous to say the least.

Chris :)



 
All,
Well, at the very least, I have found all the "Arguments" to hold merrit. My objective is to discover the current "Theories" on why to choose one method vs. another. Ultimatly, I will choose based on my own comfort level, experiences, and weighing of the "Judgements" that people make on their advice. Note the subject is "Theory", and I'm approaching it as such. Thus far, my assesment is this:
I like the idea of .DBC's, but I'm not yet experienced enough with them to take "Immediate" advantage. Table and Row buffering remains a mystery to me, as does "Binding" text objects to database fields. I can say, the mention of them has me looking for more information, and I'm very curious about their implementation.
I attended a couple of DevCons when 5.0 was released, and the one that followed, and the "Panel" seemed hot for the idea of Table/Row buffering.
I've acquired two books, "Using Visual Foxpro 6" from Que, and "Visual FoxPro 6 Enterprise Development", both of which are extreemly helpful... most of my questions usually stem from having no clue what the hell they are talking about, so I pose the question or "Theory" here.
I thank all of you for your opinions. You have all been a great help to me, and I hope to pose many more questions in this endevor.
(I actually feel like I'm begining to get it... tonight I actually used my very first ever Timer Object, successfully as well, I might add. That was cool!) I'm also beginning to figure some of the Methods out, and when they are "Called".
Thanks to everyone for their help.
-Scott
 
Scott,

<<I've acquired two books, &quot;Using Visual Foxpro 6&quot; from Que, and &quot;Visual FoxPro 6 Enterprise Development&quot;... >>

I've got both of those books. &quot;Using Visual FoxPro 6&quot; is a pretty good reference.

&quot;Visual FoxPro 6 Enterprise Development&quot; *looks* good, but a number of the exercises and examples leave a lot to be desired in real world application. I can recommend using this book as a starting point, but don't accept it as a definitive reference. Keep looking for code and theory examples. This forum and the Universal Thread are excellent sources.

Regards,
Thom C.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top