As of today, Access365 decided to prompt me for a username and password whenever I try to open a database:
This happens even when opening an new accdb-Files, so it's definetly not file-specific.
Additional Info: This started occuring after I opened an old legacy Acc2003 mdb-database that required a custom workgroup stored in an mdw-File.
"C:\Program Files (x86)\Microsoft Office\root\Office16\MSACCESS.EXE"
"Y:\CH02 Human Resources Schweiz\HR-Vertrieb\Alabin\Alabin90\alapgm90.mdb"
/wrkgrp "y:\CH02 Human Resources Schweiz\HR-Vertrieb\Alabin\Alabin90\Baslersys90.mdw"
That link has been used for years by my colleagues, and is only been adjusted to link to the Access365-Path.
Despite the custom workgroup the database itself wasn't password protected, only the VBA-project.
Could there be a problem with the custom workgroup, that screws with some system default?
Any hints are appreciated.
Cheers,
Martin
Sounds like someone messed with the system workgroup file settings.
The system workgroup file is the workgroup file used when opening all Access databases. If that workgroup is password-protected, you will always have to enter a password when opening a database, even if the database itself isn't protected. Generally, you want to avoid using a protected system workgroup file.
You can find this setting under HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Access\Access Connectivity Engine\Engines\SystemDB (where 16.0 is your office version). Afaik, you can delete the entire registry key without problems.
It's not that unusual for an Access database to register the system workgroup file on opening to avoid requiring custom links. That's a terrible practice, though, and causes this exact problem.
I have created quite a large Access 2016 db. It is now ready to share with the business and needs to be put onto SharePoint. I've tried just uploading the file to a SharePoint document library, however users cannot edit the database (there is a lot of VBA code that runs SQL commands that write data input by users into the database).
Is there a way to share the database that allows users to open it from SharePoint and let the VBA write to the database/tables?
That is not possible as SharePoint isn't an SMB fileshare, neither is OneDrive, DropBox, etc.
The SMB fileshare is offered by a Windows Server or a Linux box with Samba installed.
This question is in reference with the question -
How To Protect Database Files From Copying In Windows
I have stored the database in a computer not connected through internet and provided to the user. The database is used by an application which i have written.
The user who logs in to computer is an adminstrator level user in Windows OS .So he can read/write copy files without any restrictions.
The user accesses database thorugh an application with a fixed password known by the application.
As i have confidential information in the database which i do not want the user to access, i would like to restrict the computer owners access to database.
The user can still copy database files and view database in another system with out knowing mysql password.
I have tried to encrypt Drive using Bit Locker software but as soon as i copy the file in other hard drive/USB media i can see it in plaintext on USB media.
Are there any tools available to prevent users from copying the database files while still allowing applications to access or write data to database.
My client has asked me if it is possible to integrate his existing Microsoft Access database with his Linux shared host website. He has been keeping records of his customers' data on his local computer using Microsoft Access, but now wants to enable them to view their data online. Before I get back to him with the best approach, I wanted to ask a few questions here.
Currently it seems like I have two viable options:
a) Convert his database(s) to MySQL or similar and allow him to continue updating the databases with a web-based interface rather than the Microsoft Access desktop client.
b) Allow him to continue using Microsoft Access, and allow him to upload the updated files to a script that will parse them and then update a MySQL database.
I did some research regarding using the Microsoft Access database directly on Linux, but it seems ill-supported and not the best option.
Obviously option b would take a lot more work, but I am afraid he will resist changing from Microsoft Access to a web based alternative for updating the data. I just wanted to get some feedback before getting back to him.
So, what is the best way to integrate my client's existing MS Access database with his Linux-hosted site?
You can query a Microsoft Access database with PHP using PDO, but it probably isn't the most robust option for the web. Access is designed to be a single user database, and you will probably run into moderate to severe performance issues.
A guide on how it can be done can be found here: http://phpmaster.com/using-an-access-database-with-php/
About 7 years ago I had a similar problem, and we ended up converting the database to MySQL and let some users interact with the data via Access, which gave us a database that could be used on the web, and a familiar interface for users who refused to change to using the web, though your mileage may vary: http://dev.mysql.com/doc/refman/5.1/en/connector-odbc-examples-tools-with-access.html
Why not consider moving the tables out to something like SQL server, or use MySQL and then continue to use the Access front end on the users' desktops?
It seems to me that there is some wide spread confusion about the difference between what we call an application. An application has what we call a UI (user interface). This means you have user code, the user interface such as forms, and things like reports.
This part of the application is built using a development tool such as MS Access.
When building an application with MS, Access, or Delphi, or C++ or VB, you THEN ALSO have to choose the database system to store that data. So if you write an Application in C++, Delphi, VB or in this case MS Access you are THEN FREE to choose an appropriate database system for use with that development tool. Often people one developing application software with MS access will choose to use the default and file share based data engine called JET (or now ACE, since there is a new version that has 64 bit support and also store procedures).
In other words, you can continue to use this application, but simply link the tables to SQL server or in this case an instance of MySQL running on the web server.
So I'm not sure why there's such confusing here and people failing to distinguish between a database system you choose to work with? And that of using a tool like MS Access to build and develop software with.
I mean what's up next here? We going to call VB or c++ a database? It just seems spectacularly silly for people to not grasp and understand in our industry the difference between a database system, and that of the software development system.
I'm not sure where or why such mass confusing occurs here, but I certainly hope people are not being paid by someone or doing consulting or actually receiving billable hours on work in which the basic understanding and difference between a database and an application system is not understood! I am tempted to go off on a rant about the horrifying state of affairs and lack of education in our IT industry, but I shall refrain from doing so.
Anyway, I been using cheap low cost web hosting and deploying the MS Access applications to people's desktops for more than 10 years now. And I simply link the application to the instance of the database running on the web server. I started out doing this using MySQL, but for the last good many years I've been using SQL server (and I've only been using SQL server due to me being more comfortable with it).
So there's nothing stopping you from moving the data and tables to an instance of some type of SQL server or MySQL running on that Linux server. You can thus continue to use the Access application "as is". In this way fully 99% of the code and forms and application should continue to function without modifications. There might be a few small bits and pieces and a couple of lines of code in the application that don't work, but that shouldn't take more than a few hours of time for any experience application developer was familiar with Access as a development tool.
The beauty of such a setup is that any type of web interface you build will now instantly be seen in any of the access forms on the user's desktops. And any updates by users in Access forms and by Access VBA code will thus instantly appear on the web site because they're sharing the same database system.
So I think the best approach here is the first thing is to grasp the difference between an application built in using Access, and that of the database system you choose to use with Access.
Last but not least, Access does now have web publishing, and you can see how I change to running this Application in Access to 100% browser based in the following video:
http://www.youtube.com/watch?v=AU4mH0jPntI
However, the above does require what is called Access Web Services. And in fact it is based on a set of Web Services and a new interface that been added to Access – as such this setup would not be appropriate in this case unless one is running office 365 or SharePoint.
Commercially there are a few options. Here are a couple from Easysoft that may help when connecting from PHP-ODBC or PDO :-
The Easysoft ODBC-Access Driver, this can connect on Linux to a local access database or using Samba to an Access database on a remote Windows machine. If you were to use Samba you could access the MS Access database at the same time as other users.
The Easysoft ODBC-ODBC Bridge, this is a client server install where you put the client ODBC driver on Linux and the ODBC-ODBC Bridge ( OOB ) server on Windows. You then end up with PHP program -> OOB client -> OOB Server -> MS Access ODBC driver -> MS Access database.
Both solutions have there advantages and disadvantages but they should both fit your requirements. You can get a trial of the software from the Easysoft web site.
There is a new software tool, the CNS Media GateWay, you can use.
You can connect from any custom application or platform like Linux to MS Access, Exchange (2000 - 2013), MS SharePoint, Dynamics CRM, Dynamics NAV and many more via the CNS ODBC and JDBC driver, thus accessing, for example, the entire Exchange mailbox from your custom application.
I hope that this post helped you to answer your question.
for more info visit:
http://www.connecting-software.com
I just did something similar for a project that could not move the database out of Access and did not have the budget for a third party driver. And it was a big headache so documenting my solution here for anyone else who runs into this:
On the Linux server we can mount the Windows network drive that contains the access database and then load a table into memory using the Meza package. This was needed to know what changes we wanted to make to that table.
meza.io.read_mdb(path, table='TABLENAME')
To actually make updates in the access database, we moved the set of changes we wanted to make into a .txt file on a shared network drive (that we mounted above). Then on the Windows server we can read that file in with a Powershell script, generate the appropriate SQL in that script and execute that SQL on the Access database.
$conn = New-Object System.Data.OleDb.OleDbConnection("Provider=Microsoft.ACE.OLEDB.12.0;Data Source=$YOURACCESSDATABASE;Persist Security Info=False")
$conn.Open()
$transaction = $conn.BeginTransaction()
$command = $conn.CreateCommand()
$command.Transaction = $transaction
$command.CommandText = "UPDATE [table] SET [col]=#PARAMNAME"
$PARAMVAR = "Set a parameter value"
$command.Parameters.AddWithValue("#PARAMNAME",$PARAMVAR)
$command.ExecuteNonQuery()
$transaction.Commit()
In my workflow, I have the Linux python script loop and sleep waiting for the changes to be made and then the Windows Powershell script truncates the .txt file when it done making the changes which is what Linux python can check for to know when it's ready to continue.
A few notes:
Requires Microsoft Access Database Engine 2010 on the Windows server which you can download here: http://www.microsoft.com/en-us/download/details.aspx?id=13255
Powershell has to be running x86 architecture so I added this to my Powershell script:
if ($env:Processor_Architecture -ne "x86")
{ write-warning 'Launching x86 PowerShell'
&"$env:windir\syswow64\windowspowershell\v1.0\powershell.exe" -noninteractive -noprofile -file $PATHTOTHEPOWERSHELLSCRIPTYOUARECURRENTLYRUNNING' -executionpolicy bypass
exit
}
If I have an MS Access frontend that connects to an MS Access backend, is there a way to hide/permission block the pathway to the backend's folder such that they cannot access the backend database without severing the frontend/backend connection?
Right now I can't dedicate a server to a more "secure" form of DB or anything like that so I'm stuck with MS Access for now. I just don't want someone looking at, say, a link table path and then navigating to that folder and getting access to backend information. What might be some solutions to this?
With MS Access 2003 you can get some protection from user-level security Be very careful, the forums are full of people who have permanently lost access to their files. You should also create your own menus and compile. It is possible to disable the shiftkey open and all built-in menus, once again, this can lock you out of your file.
I know you have mentioned it, but I highly recommend that you migrate the backend to SQLExpress. The security model is much better and safer to use. SQL Express does not require a dedicated server and performs well on the desktop.
I think you can password protect your backend file.