Database sluggish after Citrix Update (1 Viewer)

[isladogs]

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.

 

[Pat Hartman]

Access does have problems in certain cases with extra dots in file names. But not with extra dots in the application database name itself. I used to get .csv files from a Unix system and those people were dot crazy. I couldn't open the files using any standard import method. I had to use FSO to rename the files to remove all the extra dots. Then I could use standard import methods. So, that tells me that the Access.exe itself doesn't have a problem but code inside the Access.exe that runs when my app uses VBA to execute standard import methods is/was never updated to ignore extra dots.

 

[isladogs]

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: 日本語のキーボード= Japanese keyboard

• attempting to import from 日本語のキーボード.csv fails
• importing from the same file name as an Excel file 日本語のキーボード.xlsx succeeds

 

[NauticalGent]

they got a red banner, wording similar to "Macros in this file have been blocked since the file is untrusted".

Have you removed the "Mark of The Web" flag?

 

[KitaYama]

attempting to import from 日本語のキーボード.csv fails

I'm sure you know this, and though it's irrelevent to OP's case, but for others who see this FAIL, I'd like to add this:

In short terms, a Japanese system doesn't fail to import 日本語のキーボード.csv

Spoiler: In Details:

In Windows, adding a language, and changing the locale is very dfifferent.

By adding a languge mostly 4 section changes:
Display language (changes the language of menus, settings, and interface)
Keyboard layout (lets you type in that language)
Speech and handwriting recognition (Adding auto correct)
Regional formatting preferences

Changing OS locale:
The system locale affects how non-Unicode programs display text.
It determines how non-Unicode legacy apps (e.g., older software or games) interpret and display text.
It sets the code page used by these programs (e.g., Shift-JIS for Japanese, Windows-1251 for Russian).
It affects some system-wide formats like currency, date, and sorting in certain legacy contexts.

As you see, adding a languate is more of a visual change. And it doesn't change OS behavior.
That's whay your system fails to import a text file (csv) in Japanese. Because you have only added some visual preferences to Office and the engine behind Office (OS) is still the same.
But for us, on this end of the world, who have changed our locale to our language, it doesn't fail.

 

[isladogs]

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.

 

[isladogs]

Have you removed the "Mark of The Web" flag?

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

 

[NauticalGent]

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

Happens to us all the time. I found a PS script that removes it from all files in a Folder and any sub-folders.

 

[isladogs]

I use a right click context menu item to unblock files