Search results

Forgot to say earlier: If you move the same faulty code to the Form_Close event, the same error occurs but the form closes successfully on clicking End. Hopefully its obvious why.

I only use A2007 for occasional testing & there is no code used to hide the ribbon. I did see something odd however in A2007. I increased the tab ctrl width so that I saw left/right arrows in the page header area. I then clicked the second tab and the first tab disappeared That behaviour...

Yes

Also in A2007 with no code Despite the caption, both are centred. I tried overlapping windows & tabbed docs, popup & non popup. Then I added the same code - no change -for me both are still centred!

OK - forget the request for a repro database. I now understand what you meant in post #1 but its NOT due to a recent change in form behaviour. I added the Form_Unload code in a test db with no frmLogin Agree that you can't close the form except by using Task Manager in Access 365 ((tested in...

@riktek I can't replicate your issue either with ampersands in tab page captions or even with a form caption in tabbed documents display. Whatever I try, the captions are always centre aligned:

Bleeding edge? The screenshot in post #4 doesn’t show the update channel, version and build info. Please provide another screenshot of the info to the right of the About Access button Sorry but I can’t quite follow your explanation in post #1. To save time, please can you provide a simple repro...

Ah that’s much better 😌 However that suggests it took about 1 second per file to open, analyse, modify, save and close again. That sounds a bit unlikely to me.

I've only just noticed this thread. Apologies if the following has already been mentioned. Access 2000 is not officially supported in either Windows 10 or 11. It is functional but performance may never be optimal The earliest supported version for Win 10 is A2007. For Win 11, A2010 is the...

I use a right click context menu item to unblock files

Good point. Strange that point got overlooked at the time.

Hi @KitaYama Yes I was already aware of those details but I’m sure they will be useful to others The interesting thing for me is not that the CSV file fails when importing to e.g. en-gb but that importing from an identically named Excel file succeeds.

You only need to provide the problem queries saved in SQL view together with the related tables containing a couple of records of dummy data. If it helps disable Monaco in the repro database No forms/reports/code needed

I don't have a Unix server handy but any previous problems importing from csv or xlsx files with a dot in the name have been fixed at some point. However, attempting to import data from text files with some Unicode characters in the name can still cause problems. For example: 日本語のキーボード=...

As I said, a quick test of creating an ACCDR file and saving to a non-trusted location would have instantly answered all those questions.

Not sure who that comment is aimed at. In my case, it wouldn't have made the slightest difference. For the OP it might have reduced the characters for the field below 1024 but it would still have displayed the issues in my examples Hopefully the OP will return at some point to respond to later...

I wondered whether anyone would pick up on that point. A simple test would have answered all the questions in your post I moved the ACCDR file to a convenient non-trusted location - in this case my local desktop folder purely to show the message that appears using ACCDR files in non-trusted...

No problem. Thanks Even at say 10 mins per file, for 500 files you are talking about 80 hours or so. Thats a long time even if you weren’t at the computer for most of the time!

Just out of interest, what does ‘pretty quickly’ mean for a typical MP3 file? 10s or 10 min or ….? Also does it work for other audio file formats such as FLAC?

👍