Things to watch
for in code
Pick code (so called data basic, or mv-basic) is easy to write, and it is easy to manipulate data with. Trying to manipulate a "piece" data in VB takes considerably more effort then it does in mv-basic.
In fact, difficult might not be the best choice of words.
In VB a different approach is required
VB has an advantage over Pick in that you can use SQL in code to update records. Notice I used the word "records" here. I did not say a record! In VB we don't have an equivalent dynamic structure that Pick has. Collections in VB come close. I use collections in VB quite a bit, but they still don't cut it when compared to Mv-Basic (nor can you easily save a collection to disk). When you have a minute, look at my object example in Appendix 3
The event driven model
Pick code is not a event driven environment like ms-access (the front end for a Pick system can be however). Hence, while in ms-access you build screens, those screens have a lower re-use then when compared to Pick code. If you DESIGN ms-access screens with re-usability in mind, then a lot of productivity can be recovered. If you do NOT design the screens and code with re-use in mind, then development time for ms-access will increase dramatically.
On the right you see a typical
event System in Ms-Access.
The form Search Tour asks the user
for a Tour Name, and then displays the
matches in some "hit list".
When the user clicks on a "hit list",
a Form to book the tour is displayed.
Now, let us assume we want a form to
maintain these Tours. Hence we
create a form to search for tours
When the user clicks on the "hit list",
the form to maintain the tour is displayed
Notice how we cannot use our first form
"Search Tour" Again. The reason for this is
that when we click on a entry in the "hit list",
we need a *different* form to load.
Hence we would probably just "copy" the original Search Form and use it. About the only thing that changes in this case is the "next" form loaded when we click on the hit list.