I really want to understand how the various tools ASP provides can work together. Dept programmer tends to look at micro scene, I want to look at macro picture as I'm writing the micro.

I have in mind a rather complicated set of apps for dept intranet; dept programmers even consider it to be, although I (perhaps naively) think a basic understanding of overall concepts is "all" I need. They will not have time to devote to it, but I've needed these solutions for years and I'm only just actually using ASP (about a month, but picking up quickly). I mapped out ages ago what I want the overall apps to do, and I have a pretty good sense of how they are actually interconnected.

I've inhaled Wrox's ASP 3.0 (read through 2/3 of it last weekend, and understood what I read, including code) -- but I need more context on:
*distinction between Record object and Recordset object
*when to use GetRows vs. simply perform operations on Recordset
*distinction between when to use Filter property vs. SQL statements --are these complementary? e.g., SELECT a less specific group of records for RS, then filter it later for individual actions?
*when it is useful to define objects
*when it is useful to create components

The immediate app involved is to enable development of new products partially based on existing core ingredients. I instinctively feel that objects and/or components are how I should define/store/make available info on the core ings, in order to have clean and reusable code and to run efficiently AND be easily maintained. Dept programmer advises using dictionary objects for each of 10 fields in a given record so that each could be acted upon independently in later use. A given product could have up to 50 ingredients, so I could end up with 500 individual fields to write to the db... Perhaps this dic obj can be incorporated into objs and/or components, but we're not starting out that way, and it feels like there's GOT to be a better way. I want to plan overall apps as efficiently as possible.

We're currently adding a dictionary array to a function to assign unique ingredient name to values passed to the function; calling the function within a Select Case statement. While this seems IMMEDIATELY practical (and well thought out), I wonder how well it serve down the line. (I've been exploring simple subs, which seemed practical for a packaged object...again, this may be simply the 'newbie' speaking.)

Immediate app would read from a db (one or more tables), display to user, enable input boxes for SOME fields, confirm user's changes, write to db; there will be add'l fields in input form that do not come from db. We want to save discrete versions, as well.
App to create new products:
1. Ingredients have static attributes (set these up as objects?) AND dynamic calculated fields, based on user input
2. Display recordset of existing product (with only a few of the attributes immediately visible) that contains a subset of these ingredients (set up this feature as an object? or simply run full SQL statements for each new product?) (Four to 10 prods quarterly...)
3. Enable selection of additional, unique ingredients for new product based on certain criteria (purpose, product category, etc.)
4. Enable input of completely new ingredient content
5. Display dynamic screen to user (i.e., show user his/her changes and confirm/modify)
4. Save all to a different db table; save subsequent versions without overwriting.

Add'l elements of this app and/or other apps within overall picture:
a. evaluate ingredient against regulatory criteria and display messages for product developer (eval code seems MADE for object; I've set up some of this in functions so far... I'd like to DISPLAY this both to guide prod developer and separately as a final summary for QA)
b. enable developer and/or QA to VIEW applicable text of individual regs, as applicable by product type, claim, etc.
c. automatically generate label copy from input (I've written code that will do this, but it is based on preliminary input form that is not yet connected to prod developer screens)

There's much more to this--but I'm sure this is more than anyone wants to read already.

Some more context:
I'm using Access, reasonably comfortable with it. I've taken courses in VB and Java, although I was terribly confused at the time (couple years ago). Generally speaking, I'm 'aware' of objects, stored procedures, etc. I've used queries in Access, but programmer does not want to employ any Access features other than the table itself.

If this matters: we're running Windows Server 2000.

THANKS IN ADVANCE for helping the 'newbie' get a grip on all of this!!

everlearning!

Do you still need help with this?

When I first read your post, I found it a bit too much to digest at once.
Also, the fact you're asking for a "broad overview" while at the same time asking very specific technical questions (when to use GetRows Vs operations on a Recordset) make it difficult to provide a to the point answer.

I can imagine that a week later you have found out a lot more, and may have more specific (??) questions about this topic.....

Imar
---------------------------------------
Imar Spaanjaars
Everyone is unique, except for me.

Thanks for responding -- I realize it is quite a lot to take in and that "concept" question doesn't seem to fit with the detail. Since I posted it, I have indeed learned some more and also begun studying the books Designing Active Server Pages and Code Complete 2nd Ed. I may have obviated or answered some of my original questions -- but I've developed new ones, too! I'll think about it all some more before continuing with specifics in this forum.

Separately: I like your signature...stimulates the philospher...

everlearning!

Well, bring em on ;)

Feel free to ask both specific as broad questions; both have a place on this forum....

Imar
---------------------------------------
Imar Spaanjaars
Everyone is unique, except for me.
While typing this post, I was listening to: Two Tribes by Frankie Goes To Hollywood (Track 1 from the album: Welcome to the Pleasuredome) What's This?