Replies

SOLVED! (Thought I should let you know )
Meaning…
Since we migrated from our Unix server to a Windows server, we can ‘multi user’ access the database without any problems so far (at this moment, for example, with 4-5 users simultaneously).
Take care
Hasse

[indent]

---

– you can’t close a message opened in a seperate window with CTRL+W;

---

[/indent]
OK – shame on me – this one shouldn’t have been so hard: ‘ESC’ does the trick
Thanks to: Windows, Browser & Outlook shortcuts (pdf)

(lol) thanks for the tips and invitation – see you around

FYI… So far, the migration (included a migration from an IMAP to an exchange server) has been successful.
What I needed to work around:
– redefining filters/rules rules and warnings: cumbersome! TB let you write your own. OL offers a wizard with off course less options,…
– you can’t close a message opened in a seperate window with CTRL+W;
– each time you select a(nother) folder, it shows the first mail in the preview pane and marks it ‘read’… while I rather like to limit distractions and decide for myself when I’ll read which messages (and hence have them marked unread)… This default preview pane setting – has to be set (off) manually for each folder. Fortunately, using Options – Other – Preview Pane) you can keep your messages ‘Unread’ if they’re only shown in the Preview pane… (or ‘read’ only after X seconds – but that was no solution in my case).
– you can’t hide the favourite folders pane – but fortunately you can minimize it.
– no ability to define your own tags (now ‘categories’) and assign several to the same message
– no quick search text box (TB right upper corner);

Nice:
– having several accounts opened at the same time in the left pane, presented as folders one below the other (hadn’t figured out yet if & how that can be done in TB)

Fwiw… in case Hans’ suggestion won’t work: how big is your excel sheet?
I had Excel once show similar behaviour (and more weird things) when I tried to extend a model spreadsheet to some ten thousands of rows… and the file to > 20 MB on a not so powerful computer.
Unfortunately I can’t remember what made it work again, besides shrinking down again to less data…

Thanks, Hans… also for the interesting info. Now I know the cause wasn’t me .

Fwiw: now that I know how it works (and with my hope vanished that I just needed to change some general option), I might consider another option… We exchange data back and forth through excel quite often. So, rather than implementing this solution to all queries used for data exchange… it’s probably less a burden to change my default (excel) list’s sort order (on which all overview”s,… are based) according to Office’s current default. The latter will create an inconsistency between old and new lists, but it’ll be more ‘stable’ and less rectification work – e.g. when users for some reason would sort their list themselves… (anyway) – Thanks!

Thank you Hans .

Fwiw – the reason of my post: for a couple of years now, I’ve been using a (fixed) sorted list of our local partners. For some reason this list’s sorting order takes into account the hyphens.
Now I wonder if it’s MS Office which has changed it’s sorting order since (I started in Office 97 Excel or Access) or if my memory is fooling me (and then I must have made the order changes manually when I started to use that list at the time)
… as now both Access & Excel are ignoring the hyphen.
If anyone can enlighten me, please do… I’ll come over it if nobody knows… but knowing would be nice
Take care!
Hasse

Hi, all,
does anyone know how to search in Thunderbird for messages which include an attachment with name “…”?
Hasse

FYI: the page Jackson refers to has been moved to the Access MVP site.

Thanks!

Final solution proposed by our (outsourced) IT helpdesk:move the database to a Windows server… (which’ll get it’s own mapping in our users’ windows explorer).

FYI
– remaining problems: we didn’t experience any corruption (yet), but still could not access the database with multiple users (except, apparently, the first time we tried… but that’s typical I guess?). It seemed like the *.ldb file still doens’t always disappear after the last user has ‘left the building’,…
– their explanation: the software which facilitates the link/correspondence between the unix server and windows workstations (Samba, Reflexion,…) always has it’s imperfections… and in our case (Reflexion) it ‘s apparently causing you can’t access the database with multiple users and a increased corruption risk.

[indent]

---

I would develop a single .mde frontend in Access 2000 (in Access 2000 format, obviously). All users, whether they have Access 2000, 2002 or 2003 (or even 2007) should be able to use this .mde.

---

[/indent] Thanks Hans.
Funny: I’ll have to use that one collegue’s pc to create the 2000 front-end, as it’s not possible from 2003 on my machine…
Take care!
Hasse

[indent]

---

I wouldn’t convert the database. Access 2000, 2002 and 2003 can all create, read and edit databases in Access 2000 format without conversion, so staying with the Access 2000 format ensures that users with any of these versions can use the database.
The Access 2002/2003 format greatly increases file size, and is less stable than the Access 2000 format – many developers have experienced problems with it, so that’s another reason not to convert.

The only disadvantage is that you can’t create an .mde database from an Access 2000 format .mdb database in Access 2003, only from the native Access 2002/2003 format.

---

[/indent]
Hans,
should I expect any of the 2002-2003 problems you described when employing a 2003 mde front end on a 2000 backend?
Hasse

FYI: in order to avoid Multi user problems, I guess it is still advisory to use an mde front end.
But since we have (now) Office 2003 installed, with still one user in Access 2000, I’m actually working like this:
– delevopment in Access 2000 format
– back-end remains in Access 2000 format
– front-end is a 2003 mde (except for that one 2000 user).

FYI… at some point… even after a migration to the Access 2000 format, we could not access our database with multiple users anymore.
Our IT helpdesk came with a double solution:
– install jet35sp3.exe
(this might have caused at least part of the problems we were having when using the Access 97 format – makes me feel pretty stupid as I thought I had checked that)
– network drive NFS properties ‘File locking’ and ‘File sharing’ must be set OFF (*).
(which seems to have been crucial, also in higher version(s) of Access)
Now we can access the database again with multiple users at once… probably thanks to the latter.
One user already let me know that the database is faster now too.

So… apparently the system which makes our Windows communicate with the UNIX network prooved quite important.
I’m not an expert, but I found a substantial article here discussing issues with SAMBA file locking/sharing which seem very similar to what I had to cope with here.
This might (!) be applicable to NFS too (but I might be mixing up things here).
(Just) some excerpts:
[indent]

---

UNIX or NFS Client-Accessed Files

Local UNIX and NFS clients access files without a mandatory file-locking mechanism. Thus, these client platforms are incapable of initiating an oplock break request from the server to a Windows client that has a file cached. Local UNIX or NFS file access can therefore write to a file that has been cached by a Windows client, which exposes the file to likely data corruption.

---

[/indent] [indent]

---

Multiuser Databases

Multiuser databases clearly pose a risk due to their very nature they are typically heavily accessed by numerous users at random intervals. Placing a multiuser database on a share with oplocks enabled will likely result in a locking management bottleneck on the Samba server. Whether the database application is developed in-house or a commercially available product, ensure that the share has oplocks disabled.

---

[/indent]
I hope this makes sense… and could provide some solution to others as well…
Take care,
Hasse

A lot of useful advise .