Replies

Thanks Hans. Your suggestion works. But looping through all the controls in the form appeared to slow down Access slightly in an old machine. I tried and managed to make the one unbound textbox editable by the codes below, where NotSetEditable is a boolean variable set earlier:

Private Sub txtUnboundTextBox_GotFocus()

If NotSetEditable Then
Me.AllowEdits = True
End If

End Sub

Then I put the similar lines in Form_Current()

If NotSetEditable Then
Me.AllowEdits = False
End If

It appeared to work and a tad faster. But I am not sure if there is any caveat in my approach.

Thanks again.

Sorry for getting back to you late. I am aware of the problems when one tries to compact an open back-end. In my codes, I made sure the back-end was closed before compacting it. I could do this all along with my Access application. The problem arose because I wanted to put a password to my back-end and I wanted to compact the back-end by supplying the in-built password without user’s intervention. When I tried to look for help in the on-line help file, I couldn’t get any display of help when I double-click on the index CompactDatabase in my WinXP desktop. Nothing happened. That was when I sent my SOS to Woody’s Lounge. After reading your replies in my Win-Me notebook, I started Access in it and I could get the on-line help on CompactDatabase. I managed to compact the closed back-end in my codes as :

DBEngine.CompactDatabase “UncompactBackend”, “CompactBackend”, , , “;PWD=” & PASSWORD

Now my query is : why did the help on CompactDatabase suddenly disappeared from my desktop Access? I tried again, and discovered out of the several help indices displayed, some could be displayed the help content, some like CompactDatabase couldn’t. I remembered I could display all the help content before on my desktop. I suspect the help file(s) might have got corrupted. How would I install the Access on-line help again? Do I need to re-install Access or can I just copy the good help file(s) from my notebook to my desktop?

Thanks Pat and Wendell for your help. I really appreciate it.

Excuse my naivete, doesn’t the date display format – dd/mm/yyyy “clearly” tell Acces that the first two digits stand for days, and the next two for months? If not, what does the display format signify?

Charlotte, I discover something very peculiar.

I am running A2K SP3 under Windows XP SP1. My regional option is English (United States) and in the Customize Regional Options for Date, the short date format is M/d/yyyy (the default).

The Access textbox for my date entry has the following properties:

display format – dd/mm/yyyy
input mask – 00/00/0000;0;_

When my date entry is say 16/08/1998, it is displayed as such and my program tells me it is day 16, month 8, year 1998. When I moves the focus to the next entry, the date display remains unchanged as 16/08/1998. When I click on the date input box again, the date display remains the same as 16/08/1998.

However when the date entry is 06/08/1998, my program tells me it is day 8, month 6 and year 1998, and when I moves to the next entry, the date display changes to 08/06/1998. When I put the date input box in focus again by clicking on it, it changes to 6/8/1998.

It appears that when the day entry (the first two digits) is more than 12, there is no problem. The problem appears only when the day is 01 to 12 and then Access would take it as month value. The short date format in the regional setting appears to interfere with Access date box display format.

Can you explain this peculiarity? I am out of my wits.

I am sorry my posting isn’t very clear. What I want is that all my date entries in my forms as well as in my reports are consistently displayed in dd/mm/yyyy format. I also want my users to key in the dates in the same format (including the delimiters) to prevent confusion. The date dd/mm/yyyy is the “official” national format. My program is only used locally and I can ignore locale differences in displaying dates. However, I have users from different cultural and educational backgrounds and who may set their locales differently. More likely they use their computers with settings made by the vendor without realizing the display differences because of locale setting. I have come across a few locally developed Access applications and all of them require users to make the correct Regional Settings before starting and I really find them a bother.

Based on your leads, I made the following changes to all my date input and display boxes as below:

display format – dd/mm/yyyy (my original format is Short Date)
input mask – 00/00/0000;0;_

It apparently worked okay after I tested it with different locales in my system. Please tell me in case you foresee any possible caveat in my method. Thanks Charlotte.

No, they were not used. I actually suspected that they were. I exited from my system, switched it off and started again just to make sure. But still I can’t move or copy them. BTW, there were a few such files from the same web page and I could copy or move some of them to another folder, but not two of them. The size of the two files (one .jpg and one .htm) was about 3K each. I’m still wondering what had gone wrong. I had no similar experiece with Windows 98.

Thanks for your suggestion. I am working on it. BTW, the gap is horizontal as my printout contains rows of individual records, and each record has 10 fields.

Thanks, RichUK, your sub works as I expected.

The Cycle properties of my form is set to the default – All records.

I had problems with autonumber before and Wendell had advised me to check my version of MSJET. My version of MS Jet is SP6. It looks like there is fundamentally something not quite right with my codes. I will check my codes thoroughly before I cry wolf. Thanks HansV.

Thanks HansV for your codes. Look like I have to delete the error tables and I just can’t suppress creation of them.

I might not have made myself clear. The HelpFile and HelpContextID work for forms and reports but it doesn’t works for menubar controls, at least for my program. In a highlighted drop-down menu of my program, when I pressed F1, the default Access help was displayed. Only when I pressed Shift F1 does the program’s Help file was accessed according to the HelpFile and HelpContextID set. However, only the title of the help file designated by the HelpContextID was displayed, not the body of the Help topic. My help file was prepared using Microsoft Help Workshop 4.03.

If I read the on-line help correctly, the HelpFile property works only for form or report only. It works differently (needs Shift F1 instead of F1) for menubar controls.

Well, Charlotte, my “bright” idea came about because of Microsoft’s updating sequence. If I have a Microsoft Jet 4.0 earlier than SP3, then I have to download the updates twice, one for SP3, and one for SP6. Copying the updated files over is much simpler if I have more than one desktop to update:)

I followed Preston’s pointer and visited the Microsoft’s web site and its related links. I became a little disenchanted with the whole thing:
(1) I need to know the OS version of the system that is going to use my MS Access’s program. Windows 95/98/Me/NT/2000/XP each has a different update for the same version number of the Jet engine. One that is working perfectly in Windows 98 may not work well in Windows Me, for instance, because the updated Jet engine is different.

(2) I need to ensure that the computer that is going to use my program have the same updated version of the Jet engine. To help update the targeted computer, I have to know its OS plus its updates, and the Jet engine plus its updates.

These two considerations are really a pain in the ass if I want to make certain what works fine in mine work fine in the other computers too, though they all have MS Access 2000.

Thanks Preston for giving me the valuable link.

After visiting Preston’s helpful link, I guessed the table corruption might be due to the following cause:

One of the desktops that was used in entering the data has MS Jet version 4.00.2927.17 (SP3) and mine is 4.00.6218.0 (SP6). The same back-end database had been processed by these two different builds of MS Jet. These different versions of the Jet engine might have caused the corruption.

Following your advice, I created a new table and copied the data from the corrupted table to the new one. The new table plus the autonumber primary key field are working fine now. There is no more duplicates of the key autonumber field.

Thanks a lot, Wendell.