Thanks for taking so much time to give me some insight about this process. I realize I have a ways to go before I become comfortable with all this. As far as Access/forms/subforms. It isn't that I want to duplicate them in a fusebox situation. I guess what I'm saying is I am not sure how to design/execute it all together. I need to know how take my knowledge of access and "convert" it to the theory of fusebox to use fb properly. But I need someone to explain to me how to design in fb vs access. I guess that's my key point- I'm confused on how to set it up- how/where the pieces fit together. I was hoping that someone with an Access background could say "instead of subforms you....blah blah/put all your queries together here/etc... I am confused on how to make my program functional in fb because I keep looking in terms of access! (Forms/subforms) It isn't that I want to do my program exactly like I would in Access, I want to how to design/execute a fusebox program but from an access "terminology" discussion... Does that make sense? -----Original Message----- From: Douglas Smith [mailto:[EMAIL PROTECTED]] Sent: Friday, May 04, 2001 6:42 PM To: Fusebox Subject: Emulating Bound Forms and SubForms (was Practicals of Fusebox) Whew! That's a lot to ask! Seriously though, this is a general problem with any WEB development you do, and is not limited to FuseBox. The web is generally stateless and queries or recordsets cannot be "bound" to HTML forms like they can with a Windows client like Access or VB. On the other side of things, I made some tools a couple of years ago that automated some of the form functionality you are talking about (warning, huge project ahead :-) For example, I used a list of key field values to manage or emulate my "recordset" When I wanted to go from one record to the next I hit the next button on the form, and I got the next key from the list, and did a SELECT query for that single record on the key value from the list, and loaded the form with that data. That way, if any data was changed since I generated my key list, I would not be looking at cached data, but I still had a "set" of records that I was working with. I had buttons for last record, next record, save changes, insert new, delete. I could also say things like "Record 25 of 105" at the bottom of my form. I also had an automated "browse mode" for this list, so you could browse the data, and skip to the record you wanted. It also had a "sort" feature, so the key field list could re-indexed by any field. As long as each table had their own unique key, it worked fine. You could also do queries to get the set of records you wanted, for example SELECT KeyField from MyTable WHERE Condition so you don't have to be editing the entire recordset in the form emulator. As far as joins go, I could make them display in the form, but they were not updatable using this method. I had to do a LOT of fancy custom tags to get all of this to work. Inserting new records in the same set of form tools was also challenging. As far as emulating sub-forms go, yes, FRAMES sound like a good solution. If you really want true bound forms (to emulate Access), you should go with ActiveX objects, and run them in IE, but then you are browser limited, and you should only do this for intranets, not general web sites. ASP is generally best used for this approach. See AspXtras.com At 10:42 AM 5/3/01, Janine Jakim wrote: >I have a favor of the list. Can someone who knows Access explain how to >accomplish the same type of thing by using fusebox. >1. In Access I would make a main form that is attached to a query. >2. This main form would be filled with many subforms showing specific >information. Each subform would have its own query- usually just 2 tables >so that info could be added updated. >(ie: the main form would show the client demographic info- one subform would >show spouse info- another subform would show medical history, etc/on/on) I >could have a dozen subforms on a main form. >3. These subforms would be attached to the mainform through a >primary/foreign key combo. This part was very easily to accomplish- it was >set in the form properties. In the properties section I would list as the >parent/child link the id# of the primary/foreign id#. >A user would see the main form- would be able to navigate through forms with >buttons and with permission edit add info into the subforms. > >I'd like someone to explain how you accomplish the same type of thing in >fusebox. I assume this would best be done with frames.(?) >How are the pages best set with each other and to the query to show the >information. (ie: in access linking the pages with parent/child link would >do this. So although my query for a subform may say list all the spouse >names only main form person's spouse name would show up). >I keep feeling like I understand the logic of fb, but my background and >practical experience is all in Access/sql. >Can someone please explain the fb practicals in terms of access >forms/subforms only background. >Thanks in advance. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm Archives: http://www.mail-archive.com/[email protected]/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
