Access Form 2000 is loading slowly over the network

I have an Access 2000 database that is on a peer-to-peer network. (All computers are connected via ethernet 100 to a simple 4-port switch) The database is designed with an interface and an interface. There are 2 users who connect to the server through the network. One user connects directly to server content because the background computer is on his computer. All computers have a fairly low specification: 500 megabytes or 1 gigabyte of RAM

I have one form, frmInvoice, which is based on the "tblInvoice" table. The table contains about 60,000 entries. There is also a tblInvoiceProducts table, which is associated with tblInvoice. The tblInvoiceProducts table contains about 150,000 entries.

When I open the frmInvoice form on the computer hosting the server, the form opens very quickly. However, if I open the form on one of the other computers, it opens very slowly. However, after opening, navigation recording is quick.

I think the problem is that when you open the form, Access opens the whole table and all the records are available. Am I correct in this assumption?

I need to fix this problem and welcome all suggestions.

I am going to install D-Link DNS-323 2-Bay Network Storage Enclosure and store the base database on it, as this will improve data protection / protection.

Thanks in advance

+6
source share
4 answers

"I think the problem is that when you open the form, Access opens the whole table and all the records are available. Am I correct in this assumption?"

My bet is that you are absolutely right.

If you open the property sheet for the form, select the "Data" tab and look at the value "Record Source", do you see the name of one of your tables?

Or a query without a WHERE clause, perhaps like "SELECT * FROM tblInvoice;"?

If your answer is yes to any of these questions, Access will have to pull each record from the table through the wire.

So don't do this ! :-) The key to decent performance is limiting the Record Source form to a reasonable subset of strings.

Choose some criterion that makes sense in your situation, perhaps the invoice date and build a query that includes this criterion in your WHERE clause. Basic criteria in an indexed field --- add an index if your table does not already have one in this field. You can experiment by creating a new query in the query designer ... maybe SQL View will look like this:

SELECT Invoice_ID, Customer_ID, invoice_date FROM tblInvoice WHERE invoice_date = Date(); 

This will only retrieve rows where invoice_date matches today's date.

(If you have already loaded the form by pulling all the lines to the local cache, you will not get a true indication of the speed of this request. It is better to check the request from a new access session without first loading the form.)

So, give the user a method to choose a different invoice. For example, a text box control named txtSelectDate. And in the After Update event of this control, you can write an updated SELECT statement that you use as the Record Source form.

 Private Sub txtSelectDate_AfterUpdate() Dim strSql As String If Len(Me.txtSelectDate & "") > 0 Then strSql = "SELECT Invoice_ID, Customer_ID, invoice_date" & vbCrLf & _ "FROM tblInvoice" & vbCrLf & _ "WHERE invoice_date = " & Format(Me.txtSelectDate, "\#yyyy-md\#") Debug.Print strSql Me.RecordSource = strSql End If End Sub 

The Debug.Print line will print the SELECT statement in the Immediate window, so if something goes wrong, you can view the completed statement and copy and paste it into SQL View for a new query for testing. Changing the Record Source property automatically results in access to the data source. And you can check the user entry in the "Before upgrade" text box to make sure that this is a valid date.

Another possibility is to have the first form load with a single non-editable dummy record ( 1 ). Then display the records only after the user selects the invoice. For this, you can use something like this as a Record Source record:

 SELECT TOP 1 Null AS Invoice_ID, Null AS Customer_ID, Null AS invoice_date FROM tblInvoice; 
+6
source

In addition to the excellent suggestions made by HansUp, I would add the following:

  • Detailed forms should never load for more than a couple of seconds. If they do, you are either doing something wrong, or you need to optimize your binding / code.
    Specification and reports may take longer depending on their complexity and how often people need them. In principle, if he needs something, then you need to be quick. On the other hand, if it is a monthly report, an expectation of 30 seconds is acceptable.

  • You do not say if your front end is split into the background or if you use the same .mdb for your data and user interface. If you do, stop and share your database , even for a person on the same computer as the data.
    Your internal mdb file should contain only your data tables and nothing else. The mdb front panel must be installed on individual user machines.

  • Make sure your tables have the right index for your filter and sort criteria. If you attach your form to your tblInvoice and set the property for the order by reference to the invoice, and your table does not have an index for this, Jet will have to download all the links to the invoice from the table to check their order.

  • If all your indexes are in order, Access will not load all the data to display a single record in a detailed form. It will only load a lot of data if you use a data table or continuous form.
    So the problem is probably related to something else: maybe you are attached to a complex query from your form, for example, in a combo box or in a data sheet, which is what pulls down.

  • Try to snap / untie the controls one by one to see which one has the most influence, and then focus on optimizing that particular area.

  • You can also bind controls as needed from the code. For example, you can save your form or expensive unbound controls and wait for the user to select the required record before binding it to the form / control.

  • If you have a lot of information about a form that loads related data from other queries and tables, you can redesign the form to group the data in Tab Control, and then have a subform in each tab to display the data and load it, only the user selects the tab.

  • Make sure that when displaying large amounts of data in continuous forms / data tables, they are attached as a snapshot to make them read-only. If they are being read / written, and someone is trying to download a detailed form, Access must perform an extensive lock check to ensure that the data is not being edited in several places. The more you make your data read-only, the better.

  • Last tip for better performance: create a dummy table with a DUMMY field in your backend, connect to it with the interface. Bind this table to a form that has one control for the DUMMY field. Make this form invisible and open it automatically when the application starts.
    This form will keep the dummy table open and will ensure that your interface does not have to open / close the connection to the backend every time it needs to request it.
    Locking a database is time consuming, especially over a network. If this is done very often, it can really slow down performance.
    It may not change anything for your particular case, but I found it to be good practice, because the impact can be huge.

+2
source

I found the reasons for very slow forms loading. They include: 1. The presence of active filters on the form 2. Having combined fields that allow users to navigate / select records

If I delete them, I will not have any problems or performance problems.

So that users can navigate / select records, I have a cmd button in the form. When pressed, a pop-up form opens, allowing the user to select the selected record. I save the record identifier as a variable, close the popup form and filter the set of form records, for example. select * from tblInvoice, where InvoiceId = tmpInvoiceId

works for me!

+1
source

yes Access (Jet) does not fit well into the network. To make things more complex, Access does not have real indexing tools like SQL Server does.

If I were you, I would go to one solid computer, install SQL Server 2008 R2 on it, and switch to Access Data Projects.

-5
source

Source: https://habr.com/ru/post/890851/


All Articles