Is this necessary? What are everyones thoughts

[bikebanditcom]

I found this bit of info on a site...what do you guys think of it? should i really split the database and put only the data on the lan and then the programs on each client machine? or is it fine as it is?


"In Access terminology a database can contain both data (tables only) and program objects (queries, forms, reports, macros, modules). Because most installations will require that more than person can access the data at the same time there should be at least two databases: Programs and Data.

The data database is usually stored on a server which everyone has access to. Note: If any changes are required to the table structures, the data database must open in exclusive mode. Example data name: project1data.mda

A copy of the program database is placed on each client. It is also recommended to keep a master copy on the server. After any changes are made (and tested!!!!) to the master copy, the client copies need to be updated.

Each client should have a convenient means to update their copy of the programs from the master. A simple solution is to create a 'good ole' DOS batch file that simply copies the master from the server to the client. This batch file can be placed as a shortcut on the Desktop. Example program name: project1prog.mda

The tables in the data database are then linked from within the program database."

 

[psemianonymous]

Depends depends depends. You weigh cost (in your time and effort, AND the cost of maintaining) vs benefit (depending on your database usage, as low as zero benefit to "overwhelming must-do" benefit).

For "applications" used by more than one person, I recommend you split the database (very strong recommendation if there are many users). For homegrown "helper" databases that only you use...well, you're the only one who uses it.


The huge benefit of splitting the database is (less) database corruption--thus if your application is any shade of "mission critical", split the application. Speed (and other benefits I can't remember) are other benefits - and the only downside is the cost of your time - and the time of whoever is awarded the maintenance of the database in the future.



Basically I'm telling you that yes, splitting the database is as important (or more so) than the above link describes.

 

[kewo99]

Fully agree with foolio12.
If database is to be multi-user, save yourself alot of rework and split it at the starting gate.

Ken

 

[JeremyNYC]

Actually, maintenance become MUCH easier once you split the front end and the back end.

Check out the pages on my site called Deploying Databases.

If you spend a few hours setting up a system to roll out your databases, making a change and getting it to users will be lightning quick, reversible (though smart backups), and transparent to the users--you'll never once have to visit their desktops.

Jeremy

==
Jeremy Wallace
AlphaBet City Dataworks

http://www.ABCDataworks.com

Affordable Development, Professionally Done

Please post in the appropriate forum with a descriptive subject; code and SQL, if referenced; and expected results. See thread181-473997 for more pointers.

 

[pavewayammo]

Believe me I learned splitting the DB is the best way to preserve data. I once had the whole DB on a shared drive where multi users could user it but one day one of those users moved it to their desktop (unknowingly) and then deleted it. Lucky for me I had a backup that was only a few weeks old but still lost some data.
Since then I have split the DB keeping the Back End where they can't see it.



paveway

Looking for help check the FAQ's first then do a search then ask. Worked for me.

 

[psemianonymous]

Yes, maintenance on a split db is easier--you can roll out updates MUCH more easily (and during work hours, assuming no backend/table structure changes) with a split front end. Rolling out updates on a shared MDB means waiting until 5:01PM and then importing your updated forms/reports/etc AND THEN updating your security permissions for these "new" objects. Definitely much easier with a split database.

BUT.

Moving to a front-end/back-end situation may increase the required knowledge level to manage the database. If you're running a full-blown application, this will not be an issue anyway because this level of knowledge is assumed. But if you're just a casual user trying to get quick-and-dirty data processing done, and you HAPPEN to have some forms and reports attached to the data, this is not for you.

What I'm saying is that you should try to keep things as simple as possible. Thus when you leave (and your knowledge leaves with you), the next person to manage the database has less to learn and thus has an easier time maintaining the database.

Splitting the database is one of these things which may totally flummox (sp?) a basic Access user. For applications this is a good thing (the less the users know about the inner workings, the better). For crude data crunchers that have evolved into meta-applications but have no really knowledgeable person to modify the behavior of the app, this can be a very bad thing.

Anyway, maybe I got off topic. The point I'm trying to make is that Access may be used on many levels of depth, and if you are not prepared to "dive into the deeper end", I recommend you keep things simple and leave the database unsplit. Again this statement is guarded by the stong suggestion that you split any Access application, since you will be swimming in that area of the pool anyway.

--
Find common answers using Google Groups:

http://groups.google.com/groups?group=comp.databases.ms-access

Corrupt MDBs FAQ

http://www.granite.ab.ca/access/corruptmdbs.htm

 

[bikebanditcom]

well, thanks everyone for the great advice, i will be picking up an access book this weekend and delving into the world of databases, i'm new to this but have a very fast learning ability, and i have picked this all up on my own so far, so i'm sure i can do it. i must make it the best it can be now as i dont want to do it later when like you its much more difficult. i'm not sure what you mean by application though. The company database (my baby) is for entering credits to be issued for customer (entered in a form, saved in one table) same for returned packages, same for RTS packages, and theres a sales tracking form and table for the salesmen. not a whole lot to this yet, a few other forms for logging in various parts that show up, among other things. slowly but surly getting this company away from using spreadsheets to log everything in. so with the given info, what do you guys think? should i? or shouldn't i? i think i will but i'd love more input from you guys. thanks
btw the site i work for is

http://www.bikebandit.com

come check us out.

 

[pavewayammo]

You are starting out just like I did. I had no database knowledge and work in a place that used speadsheets for tracking personnel information. Printing that stuff was just stupid. With a database I was able to add more fields and sort a whole lot easier. The database (my baby) has made my work life easier and now it keeps me busy with trying to learn new things and adding them to it.

paveway

Looking for help check the FAQ's first then do a search then ask. Worked for me.

 

[bikebanditcom]

pavewayammo,

another great thing about this whole deal, it builds job security. i kinda like the fact that the following quote was said about my database..

"I've had a quick look at your form and table set-up and have bad news for you..................The design of the table is against all database design principles in that it is completely un-normalised!"

Im slowly renaming everything and going to split the database and make it more relational..i'm learning.

 

[Jedi420]

bikebanditcom, One thing I strongly suggest to you, as pertaining to the quote made about your database: DONT JUST LEARN ACCESS, BUT LEARN THE BASIC PRINCIPLES OF DATABASE DESIGN! This will save you ALOT of time and frustration in the future. Anyone can learn how to drive a car without knowing how it works, but when something goes wrong, you pay out the a$@! It's good to be your own mechanic

-Jedi420

 

[bikebanditcom]

Ok, advice taken, i'm getting a good book on relational databases soon..i'll begin my studies, in the meantime, i figured out that problem it was due to me not useing elseifs instead, now i have a new problem which seems rudimentary in comparison to the previous one. Please let me know what you guys think. Thanks

'This statement determines the type of transaction entered by admin employees, could be either
'a charge or a credit, then displays it in a hidden control that is saved to the table
If OrderCompChk = True And Bill_Amount = 0 And TotalCreditCalc < 0 Then
Me![TransTypeTxtBox] = &quot;Delayed Capture&quot;
ElseIf OrderCompChk = True And Bill_Amount > 0 And TotalCreditCalc < 0 Then
Me![TransTypeTxtBox] = &quot;Sales Transaction&quot;
ElseIf TotalCreditCalc > 0 Then
Me![TransTypeTxtBox] = &quot;Enter Credit&quot;
End If

 

[JeremyNYC]

Bandit,

It's best to start a new thread when you have a new question. Also, you might want to take a look at the thread in my signature for a few pointers on how to get good answers.

You don't say what the problem is, so it's gonna be difficult for anyone to tell you what the solution is.

Jeremy

==
Jeremy Wallace
AlphaBet City Dataworks

http://www.ABCDataworks.com

Affordable Development, Professionally Done

Please post in the appropriate forum with a descriptive subject; code and SQL, if referenced; and expected results. See thread181-473997 for more pointers.

 

[bikebanditcom]

well the problem is that the code doesnt work, it doesnt generate the msg in the txt box like the code should, so with that info give what do your guys think?

 

[psemianonymous]

1. Still not enough information.
2. Are those textboxes and/or other form controls? If so, explicitly wrap them with conversion functions ( i.e. CBool(OrderCompChk) ) so that they are interpreted properly. Otherwise you'd be comparing &quot;Yes&quot; = True or &quot;TRUE&quot; = True, and these don't match up as you would expect. The same goes for Total_Credit_Calc and Bill_Amount, though with CCur() instead.
3. Specifically, which of the three outputs were you expecting? Which one did you get? Did this change? etc. More info.



--
Find common answers using Google Groups:

http://groups.google.com/groups?group=comp.databases.ms-access

Corrupt MDBs FAQ

http://www.granite.ab.ca/access/corruptmdbs.htm