Windows 10 End of Life

You cannot directly open the BE to do things like Compact/Repair, alter tables, etc.
Even if you open Access first with no file referenced and then use the Open option to browse the file share folder to find the file to be opened?
 
Even if you open Access first with no file referenced and then use the Open option to browse the file share folder to find the file to be opened?
You can link a blank accdb on Windows to the accdb BE on Linux, but you can't launch the BE in Linux.
 
We're running around in circles saying the same thing.
False.

However, there are drawbacks to hosting an accdb BE in non-Windows environments. You cannot directly open the BE to do things like Compact/Repair, alter tables, etc.
False. No such drawbacks exist. An ACCDB on a Linux Samba share of a directory on an ext4 file system can readily be opened directly to do each and every one of these things. I've done all of them countless times, without a hint of difficulty.

I have built several hybrid Access/Web applications where Access FE's on Windows Workstations link to db servers, such as Oracle, MariaDB, MySQL, hosted in Linux KVM's. These db servers are also linked to customer web portal apps.
Spinning off into tangential discussions of other ODBC BEs is utterly irrelevant.

If an accdb BE should be needed for linking to Access FE's, we would host the BE on a Windows box, or a Linux KVM running Windows.
The Windows box would be pointless, or at least utterly unnecessary.

A Linux box with a KVM (keyboard-video-mouse adapter) also would be pointless, and God knows how that adapter would run Windows, much less why one would want it to.

You simply don't apprehend SMB file services, or even Access files. Go implement a Linux file server hosting the Samba daemon to define shares of directories on which are mounted the ext4 filesystems of various RAID partitions, with share permissions for diverse users. Actually write, from scratch, the fstab and smb.conf files. Connect to the shares so defined with a Windows machine and open files on each share from diverse user accounts.

To be clear, no need exists to host any ACCDB back end on (a) any Windows machine; (b) an NTFS file system; (c) any share administered via Active Directory; or (d) any machine with any KVM (i.e., keyboard-video-mouse adapter).
 
Last edited:
A Linux box with a KVM (keyboard-video-mouse adapter) also would be pointless, and God knows how that adapter would run Windows
KVM stands for Kernel Virtual Machine. All Linux distros come with KVM's. It looks like AI gave you the wrong answers because your comments above illustrate your inexperienced with Linux, and accdb's on non-Windows environments. Everyone who knows Linux knows what a KVM is.
 
Last edited:
You can link a blank accdb on Windows to the accdb BE on Linux, but you can't launch the BE in Linux.

I was referring to a Linux-based file server, not a Linux app server. I didn't EXPECT to launch the BE while logged in to the Linux box. To be painfully clear, I was saying that a Windows system can launch a non-file session of Access, which gets you to the page where you can select a file to open ... and THAT file can be any Access file you want, whether FE or BE, because the work space is on the Windows machine. If you open a remote FE, you get the disadvantage of a pot-load of traffic between the PC and the (remote) FE file. I don't recommend that approach even though it is technically possible. But if you open a BE file the way I described, you can do your maintenance on that remote BE file. I've done it many times when working with databases related to the U.S. Navy's BUPERS (Personnel) systems.
 
My development machine for years was a Win10 VM running on VMWare Workstation on Ubuntu Linux. All files were on Samba shares on an ext4 partition on the same machine. I never encountered even a hiccup with an Access back end file. In fact, the machine had no NTFS partitions at all. Even the Windows VM files themselves resided on the same Samba shares on the Linux host system. I can't say what you tested but Access back end files, both MDBs and ACCDBs, can and do reside and operate without complaint on Linux Samba shares. No Linux application that I know of can open an ACCDB but that's obvious and beside the point.

To be clear, back end files don't "run" on the machine where they reside. That machine, regardless of OS or filesystem, is simply a file server. It isn't opening or running the back end file at all, just serving it to its client machine, in this case a Windows machine running Access, which opens the file. It is the msaccess.exe instances on users' machines that open both the front- and back-end files in a split Access database. Each user has a local front end file running on a local Access instance. All users' local Access instances then also open the same back end file, which resides on a remote share (Samba, workgroup, LDAP, AD, whatever). One bit of Access' magic is that it allows many front ends to simultaneously open the same back end file. Local machines' file and record locking settings configure this behavior somewhat. No back-end Access database server exists, however, just a back-end file, opened locally by each front end. In fact, one subtle optimization technique is to bind a startup or other application form to a back end table, to keep the back end file open instead of opening and closing it each time a user opens a form.

"No Linux application that I know of can open an ACCDB"
A few that can with limitation especially after Office 2016 - LibreOffice, DBeaver + UCan Access, MDB Tools or Conversion Based RebaseData API
 
You might, then, have a clue. Currently, you do not.

That might be over-the-top, riktek. I support your technical position about the nature and utility of file servers but must ask you to please watch the tone of your responses more carefully. That response violates the guidelines about direct insults. There is a difference between claiming someone is clueless and claiming that they have an erroneous belief. Please consider editing your post to remove any directed insults.
 
That might be over-the-top, riktek. I support your technical position about the nature and utility of file servers but must ask you to please watch the tone of your responses more carefully. That response violates the guidelines about direct insults. There is a difference between claiming someone is clueless and claiming that they have an erroneous belief. Please consider editing your post to remove any directed insults
You're right. Apologies.
 
I was referring to a Linux-based file server, not a Linux app server. I didn't EXPECT to launch the BE while logged in to the Linux box. To be painfully clear, I was saying that a Windows system can launch a non-file session of Access, which gets you to the page where you can select a file to open ... and THAT file can be any Access file you want, whether FE or BE, because the work space is on the Windows machine. If you open a remote FE, you get the disadvantage of a pot-load of traffic between the PC and the (remote) FE file. I don't recommend that approach even though it is technically possible. But if you open a BE file the way I described, you can do your maintenance on that remote BE file. I've done it many times when working with databases related to the U.S. Navy's BUPERS (Personnel) systems.
Understood, and what you say is true, but @riktek insists he has/can launch an accdb that lives in native Linux while logged into it. If that were possible, then Linux versions of Access and all other Office tools would be available for purchase from Microsoft.
 
KVM stands for Kernel Virtual Machine. All Linux distros come with KVM's. It looks like AI gave you the wrong answers because your comments above illustrate your inexperienced with Linux, and accdb's on non-Windows environments. Everyone who knows Linux knows what a KVM is.
We also don't conflate a kernel-based virtual machine with those running on other hypervisors. It isn't a generic term. Used generically, it is ambiguous.
 
We also don't conflate a kernel-based virtual machine with those running on other hypervisors. It isn't a generic term. Used generically, it is ambiguous.
Nice try, but you already demonstrated your ignorance by asking AI and publishing its erred results in your posts. If I were you, I would crawl back under the rock you came out of 🙂
 
Understood, and what you say is true, but @riktek insists he has/can launch an accdb that lives in native Linux while logged into it. If that were possible, then Linux versions of Access and all other Office tools would be available for purchase from Microsoft.
I don't know what it means for a file to "live in native Linux." I do know what it means for a file to exist in a file system, for a file server to provide it to a client, to be opened, and to be executed.

An ACCDB can exist without difficulty on a Samba share of a Linux or other filesystem. Neither Samba nor its Linux host system opens or executes the ACCDB. Therefore, the Linux host system does not require Access. A Windows machine as a SMB client can open or execute any file on any SMB server, regardless of whether that SMB server is Windows- or Linux-based. If running Access, that Windows machine can open, modify, read, write, save, and close any ACCDB on any SMB server, including adding or deleting tables, fields, or relationships, or decompiling or compressing that ACCDB file. Neither the operating system, nor the file system, of the SMB server has any bearing on this.
 
Nice try, but you already demonstrated your ignorance by asking AI and publishing its erred results in your posts. If I were you, I would crawl back under the rock you came out of 🙂
I didn't ask AI anything. I simply presented detailed, accurate, and reliable knowledge from decades of experience developing Access database applications and engineering Linux daemons, hypervisors, and networks, both physical and virtual, high-availability storage systems, components, arrays, and partitions, and directory services, specifically including Samba.
 
Last edited:
you already demonstrated your ignorance by asking AI and publishing its erred results

Yet another example of direct insult. And you compound the issue with:

It was warranted.

We have to get used to the idea that it is OK to technically disagree but it is NOT OK to try to insult OR to justify an insult.
Please, gentlemen, de-escalate. I'm about one more snappy insult from selectively deleting posts.
 
Yet another example of direct insult. And you compound the issue with:



We have to get used to the idea that it is OK to technically disagree but it is NOT OK to try to insult OR to justify an insult.
Please, gentlemen, de-escalate. I'm about one more snappy insult from selectively deleting posts.
Well, I'm done with him as I have pressed the ignore button.
 
Spinning off into tangential discussions of other ODBC BEs is utterly irrelevant.
Taking the opportunity to identify one tiny thing someone said that YOU don't think is relevant or interesting to the conversation is, in itself, tangential, and quite rude and ignorant, BTW.
 
While this is not specifically an MS Windows 10 issue, it is related since Intuit is disabling Turbotax under Window 10. I have been using Turbotax for years and it is one of the reasons for retaining an MS Windows partition on my computer. Turbotax is an excellent product, but Intuit is a despicable company.

Disabling Turbotax under MS Windows 10 raises a proverbial conspiracy question concerning Microsoft. Is Microsoft quietly encouraging vendors to "disable" products when they are on computers using MS Windows 10?

PS: On my computer, MS Windows 10, was upgraded to MS Windows 11 by "accident". I wasn't paying attention to what the update message said so I went ahead and clicked OK only to find out that I was upgraded to MS Windows 11. Everything went smoothly, so there appears to be no issue.
 

Users who are viewing this thread

Back
Top Bottom