#name error message on report

Topic

New Reply

ACCESS 2000, Win 98. SP various

In a report I have a number of fields that use the Format$ function.
The FIRST time the report is opened (print or preview) it functions correctly. The second and further times the report is opened each field that uses the Format$ function appears with a #name error message.
On my development PC the report opens correctly each time. This behaviour happens on each PC on the network in the user environment.

The report has worked perfectly for a long time (the original interface dates back to Access 95), last Thursday I was informed of a problem.
No new hardware/software has been installed. (or so I am informed).
There doesn’t appear to be any broken references when the user opens the report and then switches to the VB environment.

Does anyone have any suggestions?

Reply | Quote

Replies

Since the behavior is consistent across machines and it only started recently, I would have a serious talk with the network administrator. That sounds like a network issue, and there are too many possible causes to remember off hand. Chattering network cards can cause odd behavior in Access apps, I’ve seen hubs and routers cause enough of a bottleneck to create bizarre effects, wiring can be the culprit, and the servers themselves can do weird stuff.

Of all the Office apps, Access is by far the most network sensitive, so network behavior that won’t cause a ripple in the rest of Office will bring Access crashing down.

Reply | Quote

Thanks for responding, however it doesn’t seem to be network related. There has been some further developments.

To reiterate, the interface is copied from a ‘clean’ directory to the functional directory and then started. The report ALWAYS displays correctly the first time and ALWAYS with the #name in three fields on further opening of the interface. Each of these three fields contains (as datasource) something like =”Text” & Format$([dNumber], “0.00”) & ” more text”.

On my development PC it works perfectly every time.

There has been no hard/software installed in the recent past and no changes made to the server/network.

The further developments.

There is a laptop used for businesss trips that takes a copy of the interface with it. This is not connected to the network and experiences exactly the same problem.

I have modified the report and the three fields have been converted to text fields. In the OnPrint event of the report I set the caption of the three fields to the required content eg. “Text” & Format$([dNumber], “0.00”) & ” more text”. Now the report works perfectly every time.

More background: The flow of business is that a pre-calculation of sales/purchase prices is made for an offer. If the offer is accepted then an Order is created. There are two tables to store the financial information (with the same structure), one for the calculation, one for the order. Orders can have a status of new, modified and confirmed. At the confirmed stage then the financial information is locked to further change (can only be viewed as report). There is one interface for the calculation with a form and a report for modifying/displaying the financial breakdown. This report is in the Calculation interface and from there it always works perfectly (as I was informed yesterday). The Order interface has a reference to the Calculation interface for when the financial info is required. (Form/report source changed by modifying the SQL of the query they are based upon.) It is when the report is called from the Order interface that this behaviour takes place. Now it also transpires that the form also behaves oddly when called from the Orders interface. Various fields are not shown (as if it is a repainting problem) but the user can still modify field contents (so there is not a high level loop locking the form). Then at some point in the future the fields will be displayed. Again this behave is not observed in the Calculation stage.

{
Inside Calculation is a module with a StartFinance(iStyle…) function. This modifies the SQL string for a query and sets startup parameters for the form/report. When one generates/modifies a calculation then this function is called to start the form/report.
Inside the Order interface this function is called with different parameters to launch the form/report.
}

This calling of one interface from another DB has been in place for a number of years and functioning without problem. Late last year/early this year there has been changes made to the Calculation specifically with an extension to the Offers routine that now writes dates into the Outlook calendar and generates winword documents from standard templates. This means the Calculation has references to Excel, Word and Outlook object libraries. This new interface has been operating for a number of weeks and it is only last week that this problem has started.

Reply | Quote

Andy,

If your report is based on a query you can try to put the ‘”Text” & Format$([dNumber], “0.00”) & ” more text”‘ in the query and display the results of the query in your report.
I have had a problem like that and that was a solution that worked.

Reply | Quote

Thanks,
It is neater than the code in the OnPrint event.

Reply | Quote

In case anyone is interested.
There were further problems experienced on Win 98 (but not on Win 2000) and again with the first time a form was opened compared to second and further openings of the form.
Eventually I removed a default value (of a date) in a field in the underlying table and everything seems to be happy again!

Reply | Quote