dealing with the pick dynamic (mv) structure.

since ms-access does not have a dynamic record type like mv-basic, you must use class objects (or just simply increase your development time). by using class objects in ms-access you have "containers" of data (and code) that model the real world. pick accomplishes this via a multi-valued (dynamic) record structure. thus, one record in pick might be a invoice. in access you use a class object to represent the invoice (it would be a combination of the main record, and the "child" records for the invoice detail). this "conceptual" difference is critical in ms-access from a design point of view. hence, one better figure out how to use class objects in ms-access. the results will be well worth the effort.


a good question to ask when hiring a ms-access developer:

what did the last class object you wrote in ms access do?



calculated results vs. stored results

in pick it was (and still is) common to store calculated results. thus, if we have an inventory system and one "widget" is sold we would generally do the following:

in the sql model we would simply add one line to the invoice detail with a quantity field. to get the number remaining in stock we then do the following:

notice how the actual quantity (number) in

notice how the actual quantity (number) in stock does not exist anywhere in the database. to get our number we calculate the desired result (it is never stored in the actual data).

this is standard practice in sql. notice how this approach transfers business rules from code to the actual tables. this technique is used regardless of the application size, and number of users (hence, it is good practice even in a single user "stand alone"  application, which by the way is common for ms-access). i purposely used the word "tables" here, and not server. we could move code to the server, and have it update the inventory via a trigger (and a so called stored procedure). the trend is to avoid this *when* not needed.

the result of the "calc on the fly" approach is we can accept invoice orders from a palm pilot, a web site, or vb program. in all three cases we don't write code to reduce the inventory (we just add up orders, and then "calculate" the quantity in stock when needed). this is a design and paradigm shift from pick. this approach seeks to move business rules away from the interface, and move code/rules to tables. it is a important design consideration with the advent of the web, and personal order taking devices such as palm pilots. there is a performance cost in this approach. however this performance hit is much smaller than one would imagine. we also have a enormous increase of processing available today. i should add that this pick application was written without the use of the fabulous "bridge" functions that pick now has. the "bridge" functions in pick are a often overlooked means to solving the above "classic" inventory problem.

[image][image]

Service Unavailable

Service Unavailable

HTTP Error 503. The service is unavailable.