Discussion Locked

Microsoft Access Runtime Split Database

0 helpful
3 replies
Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.

Hello everyone.

I have a split Microsoft Access database on a server. There is a front end called sales.mdb and a backend called sales_be.mdb. The sales_be.mdb file resides on a server to which several users have access via a runtime shell.

Would I be better off keeping the front end, sales.mdb, on the server, would I be better of putting a copy of sales.mdb on each user's workstation and updating it with a script everytime they login, or does it not matter?

Please don't take the added complexity of having a script into consideration. Just consider performance.

Thank you.

~JMP

3 replies

by hal 9000

Now depending on what the Sales Data covers the answer varies. For pure performance having the data on each workstation will be faster with no network traffic involved, [b]But[/b] there is a down side with this.

If you are actually selling items and the DBase actually contains a listing of what is physically available you'll soon find yourself in a position of salespeople attempting to sell things that are not in stock even though it may say that they are on that particular workstation at the time there are several other salespeople who will be seeing exactly the same thing until their Local DBase get updated by which time the damage could have been done.

As an example lets say that you are selling swimming pools and you have a special on one type and you guarantee a completed install within 3 weeks. With a team of 12 sales people you could easily sell enough of these swimming pools that your installation staff could not possibly install the number sold within the specified time frame because each sales person is incentive driven they will make promises that appear to be capable of being kept according to their display but when you have 12 people doing exactly the same thing with the same data that isn't updated as they go along you could have the situation of needing enough staff to install 12 swimming pools within 3 weeks when your total install staff is only 8 people who can install 3 swimming pools in a 3 week period. That is only taking into account the sale of 1 swimming pool by each of the sales people per day. At the end of that day/time between updating the workstations the problem would be recognised and then someone would have to address it.

by hal 9000

It really depends on how one is to define performance in a sales team selling something that the company doesn't have stocks of isn't a great thing. In one instance recently a new salesperson was employed and went out on the road visiting his usual clients. The first month he got paid normally and then on the second month he didn't get any pay deposited into his bank account. The problem was that he actually oversold the products that the company had available and they needed to go running to their bank and borrow another 7 Million $ just to meet his sales to date. And that was without taking into consideration any further sales that he might make in the meantime. Being too successful can be worse than not being successful enough.

Now the same thing applies to performance I would personally prefer to have the Server hold the data and whenever something gets sold it gets deducted from the total amount available and when the next salesperson looks they can see what is actually available [b]Now[/b] and not some unknown time ago. While this is not as performance oriented as hosting the data locally it is better for the sales team as they constantly know exactly what they have got to work with not what was available x number of Minutes/Hours or even Yesterday.

Col

by techsupportspecialist

HAL, I appreciate your thorough answer, but I think you have misunderstood my question. Perhaps it's my fault for not being clear enough.

This is a split database; not a synchronized database. The front end (the end I'm considering putting on each user's desktop) contains no data. It contains queries, forms, reports, macros, modules and linked tables. The linked tables point to the backend on the server and all the data used in the front end is from these linked tables. The data gets updated right when the users enters it and his/her view of the data (entered by others) gets updated everytime he/she switches screens. The process is the same regardless of whether it's a shared frontend or workstation copies.

Thank you.

~JMP

This discussion is closed to new replies.