Front End

Navyguy

Registered User.
Local time
Today, 17:19
Joined
Jan 21, 2004
Messages
194
Front End?

I have been reading several posts on front end/back end. I have tried to find out what it is but can’t seem to get a clear understanding. Please tell me if I am correct…

You have to separate databases that are connected together;
The “Front End” only has the forms, reports, queries, etc;
The “Back End” only has the tables that hold the data;

If I am right on the above, would the “Front End” also hold tables for list boxes etc?

Navyguy
 
Your right, and listboxes and stuff depending on the contents can be in both front and backend....
 
NG,

If you split a db on your local machine. It doesn't make
much difference. The front end has links to the back ends
tables.

If you are talking about over a network, then you have a
whole new set of issues. The split db will load faster
because the forms/code and other "stuff" doesn't have to
travel accross the network. The front end can have its
own local tables for things used frequently and/or are
not changed often.

You will also see that over a net connection you don't
want to base forms on entire tables, just use queries
the have criteria to restrict the amount of data that
travels accross the net.

Just some thoughts.

Wayne
 
"You will also see that over a net connection you don't
want to base forms on entire tables, just use queries
the have criteria to restrict the amount of data that
travels accross the net."

Wayne

I am not sure what you mean here...I have been trying to use forms and have limited them data entry type stuff. I only have fields that are related to that form and not every field in the table.

Sorry if I am missing the point. As I mentioned in an other post, the learning curve is vertical!!!

Navyguy
 
search on this forum for :Optimize application", "performance", "speed up db", etc... There are alot of posts that cover setting up split FE/BE and how the best way to do this is. What Wanye was refering to is that you base all of your forms on queries that are based on your tables. Next you include strict criteria in the queries to limit/filter only a few records (or a handful) of records at a time over the network... thus improving performance - reason being that if your forms use tables are recordsources then the form must spool EVERY RECORD IN THE TABLE everytime it opens... wether you want to use every record or not...

Again, search on the topics I provided as you will get a wealth of info on this...

Also - my personal opinion - regarding recordsources for listboxes, combo boxes, etc... some people like to keep these tables local (i.e. with the forms, reports, queries, code, etc. in the FE) for performance increases. Now, while it does provide slight performance gains it does limit your access to them. For Example: You roll out your FE to all of your users and the color combo box on your form has the following options: red, green, blue (as was required by your clients). Now you are approached and the users/clients what to add the color yellow to the combo... OPPS! looks like your gonna have to roll out a whole new FE and have everyone download and install the app again all for the one little adjustment or give them access to each table through a form (if you have a lot of lookups this could be alot of extra forms/work). However, if your lookup tables are in the backend one simple change there by the admin and everyone gets the update.... A little food for thought for ya :)

HTH,
Kev
 
Last edited:

Users who are viewing this thread

Back
Top Bottom