Re: Programming for all fields in a table

>Algol, Fortran, Assembly, Cobol, C++, APL

Interesting, all very old languages, and their approach to data managing is
very different.

In fact, the code approach in today's systems is also very different. There
is TWO major changes in the code
approach from those above mentioned systems:

#1) - event driven programming

In those above old systems, you tended to write a "main" code routine, and
then that "main" routine would branch out (call subroutines etc) to other
parts of the application. Today, we don't have this traditional concept
anymore, and there is no "main" routine. Event driven programming means that
we have a WHOLE BUNCH of MUCH smaller routines, and those routines get
called when a event occurs (in most cases, this event is a button click, but
there are "many" events that occur. These events are a result of USER
actions). So, in a old system, you might prompt the user for some text, and
then do something. In the new approach, you might have 10 text boxes on a
screen, and our code ONLY runs in what is called the "after update" event of
each text box. So, in the old approach, you run code to prompt the user. In
the new approach, code runs in RESPONSE TO a event. The reason for this
change is the graphical user interface. We can't run code form a large
"main" routine, since with a mouse, we don't really know what the user wants
to do next! So, now most code is no longer called from some main routine, or
main menu code module. Most code now runs in RESPONSE to a event. This is,
and was a major mind set change from the older programming environments you
mention. So, you wind up with many smaller pieces of code. And, code runs in
response to user actions, not the other way around where your code asks the
user for input.

#2) - working with objects

Modem systems are so much more complex, then as developers you are forced to
work with objects. A good example in other responses in this thread is the
recordset object. This reocrdset "object" is a thing that lets you work with
table data. And, you can see by the responses, we even got a choice of which
object we use (ADO, or DAO). These objects are what unlocks the power of
modern systems. And, we can even create our own. You can read about that
here:

http://www.members.shaw.ca/AlbertKallal/Articles/WhyClass.html

So, at the end of the day, you will find that working with data means that
old concepts like sequential reading of a file, and even arrays are rarely
used. While a array was likely the most important data type in FORTRAN,
today, we RARELY need arrays in code since we got collection objects.

For the most part, you can, and should use sol to update the table
information. This means you do NOT have to write looping code.

dim strSql as string

strSql = "update tblCustomers set City = 'New York' where city = 'N.Y.' "

currentdb.Execute strSql

You can see in the above, that I did no have to "loop" though the data
tables as we got a "sql" engine to do the work for us.

So, in the above example, we are replacing all occurrences of a city field
that is 'N.Y.' to the correct text of New York.

Not only is the above less code, but it also allows the "engine" to do the
work, and if that engine happens to be oracle, or sql server, then all the
better (thus, the concept here is that the data processing part of code
should be sql when you can use it. And, this also is for reasons of "client"
to server. SQL means we have a split between our code, and the "system" that
can update data.


--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKallal@xxxxxxx
http://www.members.shaw.ca/AlbertKallal


.

Loading