Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

database search slow down

Status
Not open for further replies.

fs483

Technical User
Jul 7, 2002
977
CA
Hello,

I've never used VB6 and MS Access together but I am planning on a projet for a customer. I'm still in the analysis stage but I was wondering how much data is needed before access will slow down in searches. Here's the situation. I'm going to design a sales software for a computer business. A sales order is created, the sales order contains line item details. Each line item detail contains one item(product). Now each sales order, each line item and each item will be inside different tables. On average, there are 200 sales order done per day. Each sales order will contain an average of 5 line items. The inventory will have over 1000 items the first year with 100 more added every year. The table that will cotain the line items will grow very quickly, here's a quick calculation of it's size : 200 bills/per day x 5 lines items/bill x 5 days x 52 weeks = 26000 lines items per year. Is this considered a lot, a little ??? This is after one year, approximately how much performance degradation will happen after 2 years, 3 years for the same sales figures... If system performance will degrade rapidly, I will have to add new functionalities to enable the customer to archive the old data and only run on new database when it slows down, which will make the software a little more complicated. The database will be running on a 3 gig intel process 512 megs ram, 2 or more 30 gigs HDs configured in raid 1. How well does access compress it's data (all data will be strings and integers, nothing complex). My partner does program in VB but hasn't encountered this type of situation. I don't want the program to slow down "too much" and come back complaining but I don't want to do extra work either. I have thought of different ways to implement this with 2 databases (two physical files): 1 that will contain (customer data, inventory, users, system settings, suppliers) and the 2nd one will contain (purchase orders, sales orders, line items). That way, if the system starts to slow down, the customer can start with a different database(different file) for the sales order, purchase orders and line items
without the need to reenter the customer info, suppliers and others but all this is more work. If MS Access is able to handle data very well (with indexing) then I can program this all in one database (one file)... which should be much easier. Are there any examples that you are aware of for tihs kind of application (sales system with inventory management) or statistics on disk usage w/ performance with MSAccess.

Also does anyone know how to export daily sales from ACCESS to Accpac 6.0 Plus for Dos. I haven't got any replys from the Accpac forum.

Thanks

bootleg
 
As with any database system the more records that the application has to handle you start to see degreadation in speed and performance. But, I don't think you are talking about the kind of numbers that are going to be a problem especially with the proper indexing and table design.

Forms slow down with large numbers of list boxes and comboboxes if they are not filled properly with query SQL that is utilizing indexed fields for selection. I have found that it is always best to archive to a archive table old data and bring it back through UNION queries whenever I needed it. This keeps the current data tables as small as possible and keeps everything running very quickly.

I have had databases tables much larger than what you are talking about that through intelligent design of queries and processes run very efficiently. I have also seen horrenously slow combobox lookups due to non-indexed fields being searched character by character as the user is inputing data. Bad design is all that is.

My recommendation is that you will not be unhappy with choosing ACCESS to develop this database.

Good luck. Bob Scriver
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top