Wheninstalling the Access 365 Runtime on a machine that has another Click-to-Run version of Office installed, the Access Runtime installed will match that of the existing Office installation. For instance, if the machine has Office 2021 installed, Access 2021 Runtime will be installed.
The Microsoft 365 Access Runtime is not compatible with Office products installed with Windows Installer. For more information, see Office installed with Click-to-Run and Windows Installer on same computer isn't supported.
The Access 365 Runtime is like previous runtimes in that all design-related UI is either removed or disabled. The Access 365 Runtime includes the Access Database Engine which contains a set of components that facilitate the transfer of data between existing Microsoft Office files such as Microsoft Office Access (*.mdb and *.accdb) files and Microsoft Office Excel (*.xls, *.xlsx, and *.xlsb) files to other data sources such as Microsoft SQL Server. Connectivity to existing text files is also supported. ODBC and OLEDB drivers are installed for application developers to use in developing their applications with connectivity to Office file formats.
As a general word processing, spreadsheet or database management system -To be used as a way to create files. (You can use Microsoft Office or Office automation to create the files that Microsoft Office supports.)
To be used by a system service or server-side program where the code will run under a system account, or will deal with multiple users identities concurrently, or is highly reentrant and expects stateless behavior. Examples would include a program that is run from task scheduler when no user is logged in, or a program called from server-side web application such as
ASP.NET, or a distributed component running under COM+ services.
To transfer data between supported file formats and a database repository, such as SQL Server. For example, to transfer data from an Excel workbook into SQL Server using the SQL Server Import and Export Wizard or SQL Server Integration Services (provided the SSIS jobs run in the context of a logged-on user with a valid HKEY_CURRENT_USER registry hive).
MICROSOFT SOFTWARE LICENSE TERMS MICROSOFT ACCESS DATABASE ENGINE 2016 REDISTRIBUTABLE These license terms are an agreement between Microsoft Corporation (or based on where you live, one of its affiliates) and you. Please read them. They apply to the software named above, which includes the media on which you received it, if any. The terms also apply to any Microsoft
modify or distribute the source code of any Distributable Code so that any part of it becomes subject to an Excluded License. An Excluded License is one that requires, as a condition of use, modification, or distribution, that
3. SCOPE OF LICENSE. The software is licensed, not sold. This agreement only gives you some rights to use the software. Microsoft reserves all other rights. Unless applicable law gives you more rights despite this limitation, you may use the software only as expressly permitted in this agreement. In doing so, you must comply with any technical limitations in the software that only allow you to use it in certain ways. You may not
6. EXPORT RESTRICTIONS. The software is subject to United States export laws and regulations. You must comply with all domestic and international export laws and regulations that apply to the software. These laws include restrictions on destinations, end users and end use. For additional information, see
www.microsoft.com/exporting.
a. United States. If you acquired the software in the United States, Washington state law governs the interpretation of this agreement and applies to claims for breach of it, regardless of conflict of laws principles. The laws of the state where you live govern all other claims, including claims under state consumer protection laws, unfair competition laws, and in tort.
10. LEGAL EFFECT. This agreement describes certain legal rights. You may have other rights under the laws of your country. You may also have rights with respect to the party from whom you acquired the software. This agreement does not change your rights under the laws of your country if the laws of your country do not permit it to do so.
12. LIMITATION ON AND EXCLUSION OF REMEDIES AND DAMAGES. YOU CAN RECOVER FROM MICROSOFT AND ITS SUPPLIERS ONLY DIRECT DAMAGES UP TO U.S. $5.00. YOU CANNOT RECOVER ANY OTHER DAMAGES, INCLUDING CONSEQUENTIAL, LOST PROFITS, SPECIAL, INDIRECT, OR INCIDENTAL DAMAGES. This limitation applies to
It also applies even if Microsoft knew or should have known about the possibility of the damages. The above limitation or exclusion may not apply to you because your country may not allow the exclusion or limitation of incidental, consequential or other damages.
Two things. It sounds like you are trying to run the access Runtime, not full Access.
That means you might have only the runtime installed. And that, in turn, means that the version of MS 365 you installed may not include the full version of Access.
We would have to see the actual installation to comment on that, of course. The screen shot certainly implies you have the runtime.
You may also have a different version of Office, i.e. a trial version that was included with the new computer. Lookup under installed apps to see what you do have installed.
We have an MS Access front-end interface to an SQL Server 2014 DB. Our users access it via MS Access Runtime 2016. As the developer, I use full Access 2010 as we still have some individuals using 2010 runtime.
Please do not feed the trolls..... RE: Access Runtime via USB Memory stick ghloid (IS/IT--Management)(OP)17 Nov 06 20:19Thanks for the response Ed,
That's pretty much what I thought (about the ability to install the MDE wherever you want with the installation package program). I was also thinking about the other issue of what exactly the drive letter would be for the stick (different on any computer that uses it). So, I remember seeing that the install package had some options to run batch files once the install was complete. I might have it install the MDE with the runtime files on the user's computer, then run a batch to then delete it, and have some sort of shortcut created to point to the mem stick MDE instead. Seems doable.
I also agree with the difficulty of the split database. There MAY be some way to have it split, and develop some code in the MDE to check for the backend database on the mem stick drive (after first driving code to find out exactly WHAT the memstick drive is). I think that's possible, just pretty complex. But if that gets too crazy, I may have to keep the full MDE with tables and everything (easiest, but maybe not the best approach).
Finally, I agree as well with keeping the runtime files on the computer. The installer file for all of this would be on the stick, but the runtime files would have to be installed locally (if that could be changed to the stick, I'm sure there'd be all kinds of issues).
Right now, I'm just wondering if you can make the installer file with some sort of options to install the runtime files ONLY if needed (if the user doesn't have Access). It would seem kind of pointless to install those regardless.
Once I actually get the software from MS, I'll start playing more with it. Thanks for the insight in the meantime though. It helps me decide what the best approach may be.
If you have any other ideas, I'd be happy to hear them.
ThankS! RE: Access Runtime via USB Memory stick Ed2020 (Programmer)17 Nov 06 20:43You can retrieve the path of the frontend database using CurrentDB.Name
Assuming your backend will be in the same directory on the memory stick you can easily enough code the system to relink its tables every time it is opened. Let me know if you want some code.
Yes, you can have the installer only install Access runtime files if they are required (I think the user is given the option).
A few other points to ponder:
1. What will you do about database backups?
2. What will you do if the USB stick is lost (both in terms of getting your database and system back and in terms of data security)?
3. What will you do if the flash drive becomes corrupt or damaged?
Ed Metcalfe. Please do not feed the trolls..... RE: Access Runtime via USB Memory stick ghloid (IS/IT--Management)(OP)20 Nov 06 09:16Thanks again for the valued insight here.
I DO in fact know of a little code snippet to get the current drive of the database (got it here):
Dim strPath As String
strPath = Application.CurrentProject.Path
MsgBox ("It is " & strPath)
Works nice, and I also have some code to relink tables, but I believe it uses menu commands. It was something I picked up awhile back that works, but I'm not sure if it would work on runtime. Therefore, if you DO have any code samples you can share, which show how to relink tables to a database once opened, I'd sure appreciate seeing that.
Also, I have a code snippet which grabs the drive of the memory stick. It is VERY good, but it currently will work to get the drive letter of ANY removable drive source on the computer. That could be bad if the user has some sort of USB CD drive or something. I can't remember if I've tested that scenario yet, but I will look into that some more.
I am somewhat worried about the corruption of the drive and database backups. Not too worried though, but it is an issue. With this application, the users will be securely emailing the data (via certificate ID), back to our office on a regular basis (usually at least once a week). If I can figure out how to keep this thing split on the stick, I think that will really help with keeping corruption possibilities low. Maybe I'll have the user email the entire data file to our office once and awhile too. The front end portion then could be reinstalled from another installer package on the stick (we use something like that now for this application), if it ever got corrupted.
As for the security of the system (since it's all on the stick), that will be ideal. We are purchasing fingerprint ID sticks which means only select users can even view what's on the stick. I believe that's even better than having a user install this on their personal computers (there are 21 people this would be distributed too, and all have different computer setups). I'm sure many of the users home PC's would be the most frequently used type of PC, which I'm also sure is completely unsecure (no logons). Therefore, the stick idea comes in nicely for these scenarios.
Still waiting on the software here, but I'm eager to start. I'll keep the posting going with any interesting issues I run into. Hopefully not many now (talking this out in the forum REALLY helps), so maybe just a summary on how things went then.
Thanks again for all the help. Let me know if you can provide some linking tables code. I can show you the code I have to get the USB mem stick drive then too (it's rather long).
Appreciate it!
RE: Access Runtime via USB Memory stick Ed2020 (Programmer)20 Nov 06 11:39ghloid,
The following code assumes that the database backend is stored in the same directory as the current frontend.
Run it from the frontend. Pass the file name of the database's backend (not the full file path) as a parameter.
Code will first delete all linked tables in the frontend and then relink all tables from the backend.
Apologies for lack of error handling - I've just knocked this together, so you'll have to add it yourself! :)
CODEPublic Sub LinkAll(ByVal strBackendName As String)
Dim strBackendPath As String
Dim ThisDB As DAO.Database
Dim dbsBackend As DAO.Database
Dim TDef As DAO.TableDef
Set ThisDB = CurrentDb()
For Each TDef In ThisDB.TableDefs
If TDef.Connect "" Then 'Only drop linked tables
ThisDB.Execute "DROP TABLE " & TDef.Name & ";", dbFailOnError
End If
Next TDef
strBackendPath = Application.CurrentProject.Path & "\" & strBackendName
Set dbsBackend = OpenDatabase(strBackendPath)
For Each TDef In dbsBackend.TableDefs()
If Left(TDef.Name, 4) "MSys" Then 'Ignore system tables
DoCmd.TransferDatabase acLink, "Microsoft Access", dbsBackend.Name, acTable, TDef.Name, TDef.Name
End If
Next TDef
End Sub
Ed Metcalfe. Please do not feed the trolls..... RE: Access Runtime via USB Memory stick ghloid (IS/IT--Management)(OP)20 Nov 06 14:07Ed,
Nice code there. Even ignoring the system tables -- nice.
Just curious, where could I pass a password parameter for the backend database? The backend has a password on opening (as does the front end). This was done as one more security measure, primarily in case the users had to email the backend to me via a normal email account.
I have a code snippet from my last routine that used:
tdf.Connect = ";DATABASE=" & strDatabase & ";pwd=" & "pwrd"
In this example the password was "pwrd" (as you can see).
I'm fairly certain that in your routine above, the password parameter could be supplied somehwere in that OpenDatabase method you are using. In looking at the help file for the method, seems the connect parameter is used for this as shown below:
"FoxPro 2.5; pwd=mypassword"
Looks like the first part would be the TYPE of database (FoxPro or ODBC or something). Guess I would have Access in that part. It's the "pwd" syntax that follows that definition which seems to be what I'm looking for. I've just started looking at that, but that sounds right. Don't know, I'll keep checking.
Thanks again for the help. Don't worry about the error handling, I'm pretty familiar with putting in tons of code for that :). You've helped plenty so far.
I'll let you know how it goes when I actually start implementing more.
Thanks! RE: Access Runtime via USB Memory stick Ed2020 (Programmer)21 Nov 06 03:35You need to specify it in the connect string.
Although the two arguments that proceed it ar optional you still need to pass them if you pass the connect string arg:
CODEPublic Sub LinkAll(ByVal strBackendName As String)
Dim strBackendPath As String
Dim ThisDB As DAO.Database
Dim dbsBackend As DAO.Database
Dim TDef As DAO.TableDef
Set ThisDB = CurrentDb()
For Each TDef In ThisDB.TableDefs
If TDef.Connect "" Then 'Only drop linked tables
ThisDB.Execute "DROP TABLE " & TDef.Name & ";", dbFailOnError
End If
Next TDef
strBackendPath = Application.CurrentProject.Path & "\" & strBackendName
Set dbsBackend = OpenDatabase(strBackendPath, False, False, ";PWD=fff")
For Each TDef In dbsBackend.TableDefs()
If Left(TDef.Name, 4) "MSys" Then 'Ignore system tables
DoCmd.TransferDatabase acLink, "Microsoft Access", dbsBackend.Name, acTable, TDef.Name, TDef.Name
End If
Next TDef
End Sub
Ed Metcalfe. Please do not feed the trolls..... RE: Access Runtime via USB Memory stick Ed2020 (Programmer)21 Nov 06 04:04One other suggestion - I'd seriously consider setting full workgroup security on your system rather than just a database password.
Database password's don't provide particularly good security. They won't protect the design of your system in any way once the user is in, and all users will have the same level of access.
Ed Metcalfe. Please do not feed the trolls..... googletag.cmd.push(function() googletag.display('div-gpt-ad-1406030581151-2'); ); Red Flag This PostPlease let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.
CancelRed Flag SubmittedThank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.
3a8082e126