I have created .mdb (Access macro) for client but problem is that they are migrating to Office365 so access will no be longer available for them.
Can I run Access macro without MS Access? I have googled it, I found .MDE file can solve the problem, but I don't have idea about it. Is there any alternative option or .MDE file will be the solution?
I'm a beginner in Access please let me know if any suggestions are available.
Thanks in advance!
You can't.
But Access is indeed available through O365 - you just have to select and pay for the correct subscription.
Microsoft just recently changed the Office 365 subscriptions. Microsoft Access is now included in all of the subscription levels except the Business Essentials subscription.
If users of your Access application have no license for Microsoft Access they still can use the Microsoft Access Runtime. The Access runtime is available for download free of charge and can run Access Database Applications, but you cannot make any design changes in it.
Related
I'm hoping someone can either tell me what I'm doing wrong correct my flawed understanding of how this works and explain why it's not possible.
I've been developing a fairly basic database/program for a client in Access. They have Office 2007, I have Office 2010. Initial test of creating a database in 2010 (in "2007" format) and opening the forms and data in Office 2007 showed no problems.
Fast forward 3 weeks. I've sent them a recent copy for approval and they can't open it. Unrecognised database format. Upon looking around, it seems Access 2007 format doesn't really mean anything in terms of backward compatibility (thanks M$). I COULD follow the seemingly standard answer and remove empty fields, calculated columns etc but really don't think it should be necessary.
I've installed the Access 2010 runtime on one of the target systems with the understanding that it would allow me to open the Access 2010-developed ACCBD. No luck. Office 2007 still launches, and "unrecognised database format".
Is the problem that Access 2007 is installed on the target system? Or am I perhaps misunderstanding what the Access runtime distribution is for? Basically, is there a way to still deploy a program/database developed in Access 2010 without a) installing (and purchasing about 60 licenses of) Office 2007, or b) stripping back the existing ACCDB.
I haven't worked enough with A2007 and A2010 to help with the problem of A2007 not being able to open the ACCDB in which you were working in with A2010. Your understanding of how the Access runtime is for is basically correct.
However when the client was executing the A2010 runtime against your ACCDB did they create a shortcut referencing the path to the A2010 runtime msaccess.exe and the path and file name of the ACCDB? Similar to
"C:\Program Files\Microsoft Office\OFFICE14\ART\MSACCESS.EXE" "Q:\1 access\NewsgroupAnswers.mdb"
You can save in 2007 format from 2010 but one little known issue is that when you make changes in a 2007 access file within 2010 you will not be able to open it in 2007 again. To fix this you must create a -new- 2007 file and import all items into the fresh one (just compact and repair will not work) and then this new file should be usable within 2007 once more.
I've currently been using Base/MS Access to create forms etc. that interface with a backend database, to save me writing a backend in PHP. Downside is that it only runs on the desktop. Is anyone aware of any web-based equivalent?
Edit: Should have done more research, I need it to interact with MySQL, not an Access DB.
Have you considered Access 2010 : Hosting an Access DB
Depending on Access version, you could use Data Access Pages (Can be used with Access 2007+ with some additional work.). The recommended usage for 2007+ would be within SharePoint.
We're looking for an easy way to display Access reports on the web. These reports have been written and viewed internally for years. They are not simple tables, but more complex charts and graphs. But, now people outside the organization need to see them. All of the data is in access. And, except for reporting everything else is working fine.
We have a web server that has permissions to see the Access database. However, the Access database server cannot be the webserver itself. So, the question is how do we view these reports on the web? This excellent solution, which I reference in case it helps others, (https://web.archive.org/web/20211020135306/https://www.4guysfromrolla.com/webtech/042600-1.shtml) does not apply, as it requires you to be on a company intranet . (Although, it may be possible to implement the solution outside of an intranet, so many security holes would be opened up that the developer leading this project would surely be fired.) If possible, we also do not want a solution that expects every client to install code, for example, the access runtime.
Is there a tool that can read the
access reports when requested? OR
Is there a tool that can upload the
data from the Access database on a
periodic basis and based on the last
retrieved data - it can display the
report that was written in access?
Other solutions ...
Thanks!
print the reports to pdf and then copy the pdf files to the webserver
Options:
output to PDF.
output to Access snapshot format and force users to use the snapshot viewer.
wait for Access 2010 with Sharepoint 2010 and Access Services and you're home free (as long as you can rewrite your reports to be full web reports, i.e., not VBA and only using the capabilities of web reports in A2010).
We deliver an Access app (and reports therefore) over a Terminal Server as a WebApp.
As the title says, I would like to use Vault for source control of an MS Access application that contains forms, queries and modules with vb code. I want to avoid the tedious process of exporting and importing modules to and from text files for the purpose of diffing with previous code.
Thanks.
Access 2003 does work with Visual SourceSafe 6.0.
I have to assume since access does have support for SCC, then perhaps it is a standard interface? I don’t believe SCC for ms-access will work with SourceGear.
You can find info on using VSS 6 with ms-access here:
http://support.microsoft.com/kb/837136/en-us
I used SCC with ms-access. You can even check-in/check out forms or even queries. So, it does allow more then one developer to work on the application at the same time.
Keep in mind the above SCC for ms-access works by using the un-documented
Saveastext
And the reverse is:
LoadFromText
Type the above two commands in the access debug window, it will give you inteli-sense as to what the options + parameters are.
With the above information you certainly could import + export bits and pieces in and out of ms-access into Source Gear.
So it is a bit of a long shot to get SCC feature of ms-access working with Soruce Gear, but you could cobble together something that pulls objects in and out of Source Gear by using the above two commands.
The only thing I can add to Albert Kallal's answer is that I actually did use MS Access with two different source control providers - with MS Visual SourceSafe and with SourceGear's SourceOffSite.
There were some occassional problems when our team was using SourceOffSite - like sudden failures of MS Access during some source control operations - but all in all it worked. (Perhaps those problems were caused by the fact that we sometimes "mixed" those two source control providers - i.e. one developer was using VSS and another was using SOS. So I can't really blame those problems on MS Access itself.)
Now, I never used Vault. But, since SourceOffsite and Vault come from the same vendor, I think there is a very good chance that (a) SourceGear offers an MSSCCI provider for Vault and (b) MS Access can be used with Vault successfully.
Hope this helps.
I haven't tried earlier versions, but I can confirm that SourceGear Vault 5.0.4 can be used with Microsoft Access 2003 (with the Access 2003 Add-in: Source Code Control installed).
For this to work, you need to enable a option in Vault Client called "Make Vault your default SCC provider".
I've got a MS Access database with a table and a form, but I want the user to only see the form. I don't want them to be able to edit any of the data. The user should only be able to use the form to query the table. Any suggestions??
There are a few ways to enforce some control over what users can do.
AutoExec
The most simple way is to use an AutoExec macro to initialise the user interface when the application starts.
That way to can make sure that only the form you want is displayed and hide everything else.
Runtime
A good complement to this approach is to compile your application and force the user to use the Access Runtime to use your application.
In the runtime, users don't have access to all the standard tools unless you explicitly code for it.
A good thing to know is that unlike previous versions, the Access 2007 Runtime is free, and that makes Access a very cheap platform to develop for.
Runtime emulation
With Access 2007, a simple way to ensure that the application will open as if only the runtime was installed is to change the extension of the database to .accdr.
You can also force a full Access installation to open a normal database in Runtime emulation by passing the /runtime command line switch.
Secure data-access
Note that short of encrypting the database (but then you have to manage the password), all you can do is make it hard for the user to open the tables manually.
A determined and knowledgeable user can always circumvent these protective measures and access the data.
If you need a really secure solution though, Access may not be the best choice: implementing fine grained security in Access is a greater challenge than the alternatives, say storing the data into a SQL Server database for instance where security is enforced.
Links to resources
Security Considerations and Guidance for Access 2007 on MSDN
A simple Microsoft Access User-Level Security Tutorial for older versions of Access.
FormSafe, a commercial product that helps enforce security on form controls.
I believe you want to use Access User-Level Security. Here's the documentation at Microsoft.
If you are using Access 2003 or earlier, you can use user level security, as mentioned. If you are using Access 2007 you are out of luck - Microsoft in their wisdom removed this ability. You will basically have to write your own login and set permissions on editing etc. using VBA code.