Forms unbouded/bounded (1 Viewer)

Hi, I want myAccess-application in multi-user environment ((maximum 3 users) with a splitted database (Front-end/Back-end). Should I use bounded (quit easy) forms (with action-queries and ADO-Recordsets and VBA) or unbbounded forms (rather more complex).

Cross posting: http://www.accessforums.net/forms/un-bounded-forms-33198.html

Please read: http://www.excelguru.ca/content.php?184

Sorry, I didn't know there was a relation to the other Access Forum.

There is no relation between the forums. Many folks like you participate in several forums. Please read the link I provided so that you better understand why you need to identify crossposts.


Alan

Alansidman said:

There is no relation between the forums. Many folks like you participate in several forums. Please read the link I provided so that you better understand why you need to identify crossposts.


Alan

Click to expand...

Thanks for the information. Someoneon the forum was very helpfull.

The whole point of Access is bound forms/reports. That is one of the things that makes Access a RAD (rapid application development) environment. So, unless you have a very specific need, there is no need to even consider using unbound forms. The majority of my apps use SQL Server back ends and support dozens of users. Once you understand how to use form level events you have absolute control over whether or not a record gets saved. You don't need an unbound form to obtain this control, you simply need to understand how forms work and when events fire so you will know what type of code should be placed in each event procedure.

Once your data (or user base) becomes large enough to require the use of SQL Server, you need to understand how to make your app work efficiently to return the minimum amount of data. There is no point in creating a form bound to a SQL Server table that contains a million rows. You will be very unhappy with how the form performs and your DBA will be very upset about the load you put on the network. So in summary, forms should be bound to queries with criteria that limits the rows selected. If you begin with this concept, you won't ever have a problem upsizing your app. Since the client/server approach works regardless of what type of database you are linked to and the "Access" approach works only with Jet/ACE tables, why not start with the client/server approach and be a hero down the road if you ever have to upsize?

I use and need very often 'Text-fields events' (Got focus/After update).This effects updates in two other tables. Do you mean by 'Form level events' that I rather avoid this Text-fields events (this would be very annoying)?
May-be I will know what's better trying it out wit real data?

Certain code is appropriate in control events but other code belongs in form level events. For example, If you want to ensure that a field is not null but for whatever reason, you don't want to define the field as required at the table level. There is NO control level event that will successfully implement this rule. No matter how much code you put in contol level events you simply can't trap the case where the user just never enters the field. You would somehow need to completely control field to field navigation and force the user to go to every control - good luck with that and WHY would you ever want to do it? All you need is code in the Form's BeforeUpdate event because NOTHING gets past that event.

Luciano said:

I use and need very often 'Text-fields events' (Got focus/After update).This effects updates in two other tables. Do you mean by 'Form level events' that I rather avoid this Text-fields events (this would be very annoying)?
May-be I will know what's better trying it out wit real data?

Click to expand...

why would an event handler for a text field cause an update on 2 OTHEr tables?

The updated text-fields are numeric. Updating such fields in one (table-bounded) form, causes updating (calculated) fields (using the updated text-fields) in other tables.

The correct terminology is Bind or bound. Not bounded. A form is bound to a table. A control is bound to a column in the form's RecordSource. When you create a query that joins a main table to a lookup table and you use that query as the RecordSource for a form, you bind controls to columns that originate in one of the tables. Most joins result in updateable queries. That means that your form can update data in both tables. In general practice, when you bind controls to "lookup" fields, you should set the control's Locked property to Yes to avoid accidental updates. For example. You have an Order entry form and on it you have a combo that lets you select the CustomerID and the RecordSource for the Order form joins the order table to the customer table to make it easy to show some customer information on the form. So, you select customer 1234 whose name is Acme Anvils. If the customer name control is not locked, a user might accidentally change Acme Anvils to Acme Hammers not realizing that the lookup table is what is actually being changed, not the order.