I'm planning to "upgrade" the MS-Access desktop application I've developed for various customers with various Access versions - to Access 2019.
That is because of 3 main reasons:
Bigint support
Better ODBC connectivity
New technique for building graphs.
Now most of my customers run Access desktop applications through Access Runtime. And most of them have various versions of MS-Office Standard, say 2003, 2007, 2010 or 2013 etc.
It is NOT a problem to run excel automation VBA code from Access, and we use it a lot.
If we plan to use Access 2019 to benefit from all the above advantages - what kind of Runtime am I to give to the customers?
It's been said in various places that NO Access-Runtime-2019 is been planned to be built. I've talked with a Microsoft representative and he said "Your Access-2019 applications will have to be run on Access 2013 or 2016 runtime, and it is supposed to work just fine".
My 3-fold question is:
If an Access-2019 application - which uses the above features - is run with Access-Runtime 2013 or 2016 - will these special 2019 features really work?
What about Access-365-Runtime? Will these features work with it?
I've read about the problem to install newer versions of Office in the same machine where older versions exist: The 2016/365 Office uses C2R installation technique, while older Offices use MSI installation technique (see link here). So my conclusion is that my customers, who rely on the existence of Excel 2007 or 2010, for instance, while working with my Access applications - will have to abandon these 2007/2010 Offices because of the new Access-2019 applications that we plan to give them with Runtime 2016/365. Is that true?
I know users with Office 365 will do fine. My question was about trying to run Access-2019 applications - in older environments of MS-Office, like Office 2007 or 2010. After all, they had paid for those Offices long before Office 365 was developed, and why would they want to change them...
This post is another clue:
https://stackoverflow.com/questions/45715914/access-2016-64bit-mso-365-deployed-database-cannot-run-with-any-runtime-aval?rq=1
According to what's written there, Runtime 2016 doesn't support Bigint (which is one of the features we want to use Access 2019)! So when the Microsoft representative I've talked with said "Just run it on 2016-Runtime!" - He ignored (or worse than that - didn't know) that Bigint will NOT be supported! So what do we do about it now?
If an Access-2019 application - which uses the above features - is run with Access-Runtime 2013 or 2016 - will these special 2019 features really work?
No. The information you got was incorrect.
I know users with Office 365 will do fine. My question was about trying to run Access-2019 applications - in older environments of MS-Office, like Office 2007 or 2010. After all, they had paid for those Offices long before Office 365 was developed, and why would they want to change them...
Because Office 2007 stopped getting security updates in 2017, and Office 2010 stopped getting security updates in 2020. Given the fact that Office documents and Outlook are major attack vector on Windows systems, using a non-supported version of Office on an Internet-connected PC is not something your customers should do (unless they enjoy paying ransom to cybercrime gangs).
I've read about the problem to install newer versions of Office in the same machine where older versions exist: The 2016/365 Office uses C2R installation technique, while older Offices use MSI installation technique (see link here). So my conclusion is that my customers, who rely on the existence of Excel 2007 or 2010, for instance, while working with my Access applications - will have to abandon these 2007/2010 Offices because of the new Access-2019 applications that we plan to give them with Runtime 2016/365. Is that true?
Let's clarify a few things first:
Office 2007 is v12, Office 2010 is v14, Office 2013 is v15 and Office 2016/2019/2022/365 are v16.
There are MSI and C2R versions of Office products. v14 and below are MSI, v15 is mostly MSI (Office 2013 C2R exists but is rarely used), and v16 is mostly C2R (except for Office 2016 volume licenses and the Access 2016 runtime, which are MSI).
This is what we learned by practical experience:
Different MSI versions of Office can be installed side-by-side, except for Outlook. You will see the "Office is being installed..." window frequently if you regularly switch between different versions, which is annoying.
MSI and C2R of the same version cannot be installed side-by-side. Thus, if a customer runs Office 365 (which is v16 C2R), you can't install the Access 2016 runtime (which is v16 MSI).
The Access 365 Runtime is supposed to be compatible with all v16 C2R versions of Office. In practice, we had some cases where it wasn't, so we dropped support for it and required customers using v16 C2R to use an edition with the full version of Access included.
So, yes, the combination Office 2007/2010 (v12/v14 MSI) with the Access 365 Runtime (v16 C2R) should work, even though I would personally recommend against it (see the point about Office 2007/2010 being out of support above).
Microsoft 365 Access Runtime will support all recent feature updates. Just make sure that you're installing the latest version:
Microsoft 365 Access Runtime Online Installer
This is a discussion that shows Office 365 is essentially Office 2019 with more up-to-date features:
UserVoice
Related
At this moment I'm working on a MS Access database, and I have difficulties with the library MSCOMCTL.OCX.
The problem is the following: given Windows 7 x64, Microsoft Office 2010 x64 and MSCOMCTL.OCX v6.1.98.34 (which was registered with the help of regsvr32 in the folder SysWOW64), I can't use the TreeView (MsComCtlLib.TreeCtrl.2 class) present in some forms of the database. Every time the code approaches any TreeView's (read, Node's) property, I receive the following message:
"Object doesn't support this property or method" (Error 438)
while in Windows 7 x32 the database works fine.
Trying to understand what's wrong, I discovered that the library Microsoft Windows Common Controls 6.0 (SP6) exists in the list seen in the 'References...' dialog and is checked, but I don't see Microsoft TreeView Control 6.0 in the list of available ActiveX Objects when I'm in the Constructor mode.
Following some solutions found in the Internet, I executed regedit.exe and saw that there are two "folders" in the path HKEY_CLASSES_ROOT\TypeLib\{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}, "2.0" and "2.1". Besides, the path to the file MSCOMCTL.OCX is in "2.1", while "2.0" is not also empty - it contains PrimaryInteropAssemblyName property for example, which isn't present in "2.1".
So, what should I do to make TreeViews in my database work? As I've mentioned before, I saw some solutions, but I'm afraid to use them because the computer, where the database is in, is not mine and it's undesirable to make the changes, which can affect security of the system.
The version of MSCOMCTL that is installed by default is not 64-bit compatible. You're unfortunately out of luck. No amount of modifying the registry is going to make a 32-bit only control work in 64-bit office.
However, MS apparently includes a 64-bit compatible version of MSCOMCTL with Office 365 ProPlus installations (source). You can consider buying that, or obtaining it through other means.
I'll be porting an asp.net website in Net 2.0 to a more recent version of .Net 4.5.
I'm looking for more modern libraries to use for SQL Server connectivity, and I noticed that the last update for Enterprise Library was done in April 2013.
Is Enterprise Library still being used or is there something newer?
Thanks.
The CodePlex project page for Enterprise Library (which goes read-only Nov 6, 2017) says:
This project is no longer under development.
Unity has new ownership and has relocated to GitHub.
The remainder of
the application blocks will no longer be developed. However, the
source will continue to be available. We encourage any interested
parties to fork the source as desired.
So, other than Unity it's looking pretty dead. It's unclear if MS will be keeping read-only CodePlex online or not.
Is it possible to push windows 8 app directly to some not development-devices (without direct access to device)? For example, if one wants to install demo version of our app during the exhibition on devices of someone who intersted on our product.
First of all, the application deployment bypassing the Windows Store is called sideloading.
One basically has two options to perform sideloading:
Windows 8 Pro and Windows Server 8, if they are joined to a domain, are directly ready for side-loading.
Windows 8 and Windows 8 RT, as well as the above-mentioned systems without domain, require the activation of a special Sideloading key, which can be purchased by enterprises only and usually available in 100 packs (priced at $3000 per pack, $30 per licence).
The installation of the app can be done either by using the application image and DISM or in runtime by add-appxpackage PowerShell CmdLet.
Here is a good explanation of the whole process (in German).
No, it would not be practical at an exhibition to provide direct loading of your application, bypassing the Windows Store. The Windows Store is there to provide a safe environment in which to download certified applications.
It would be a far better experience if users could download from the Windows Store a trial version directly -- maybe you could provide free a wifi/network connection, and a bit.ly link or QR code of some sort to quickly get to the download for your application. :)
While it is possible to do side-loading (walkthrough) in some circumstances, it was not intended to be used in this case. It's intended for Enterprise deployment and the walkthrough article has lots of details about the specific options and the costs associated if the destination machines/Windows isn't running Windows 8+ Enterprise edition.
One other option is that you can also deploy an application for testing purposes to another developer machine (which requires a Windows 8 developer license). It would be unusual for anyone but a Windows 8 application developer to have this activated (as you know, they expire after 30 days). This may be a violation of the licensing agreement though as it is expected that this is for development purposes only. It also involves powershell, so it would be a potentially awkward installation experience at an exhibition.
It is possible dude...
Just developer unlock ur phone and deploy apps directly from PC.
Hi I am looking into a Microsoft Source Code Control Interface (MSSCCI) compliant Mercurial Client for integrating Mercurial into my IDE (LabVIEW). I thought HgSCC was getting close since it claims it uses the MSSCC interface for it's integration with Visual Studio, however it doesn't turn op in LabVIEW as an option.
Does anybody know a MSSCCI compliant client or can verify that HgSCC is indeed such a client and LabVIEW is just lazy in recognizing this one?
I looked at the registry key used by LabVIEW HKEY_LocalMachine\SOFTWARE\SourceCodeControlProvider\InstalledSCCProviders which only lists PushOK's SVNSCC client.
The first version of HgScc was MSSCCI compliant.
You can get it here (http://www.newsupaplex.pp.ru/hgscc_news_eng.html), scroll at the very bottom to the news dated "24 may 2008". There you can find a download link. Also, that version was tested only with MSVS 2005/2008, so it may not work with LabVIEW.
The recent versions of HgSccPackage supports only MS SCC Package API (MSVS only), which is not MSSCCI compliant.
Have you tried VisualHG?
I have a database in ms access 2007 with forms. I need to create a stand alone exe file from access. Is it possible? If so, how?
You can't save it as .exe, but you could use the Access Runtime to allow users without Access to use your Application.
If I can just add my two cents worth...
You DO have to distribute the Access runtimes with your application. I heard recently on Stackoverflow on a questions that Microsoft runtimes for access are now freely downloadable.
Here are a couple of links...
http://www.granite.ab.ca/access/developeredition2007faq.htm
http://blogs.msdn.com/clintcovington/archive/2007/01/30/the-runtime-and-developer-extensions-will-be-free.aspx
You can either distribute these runtimes with your application or you can have your customer download them.
EDIT - THE BELOW IS PROVEN FALSE. YOU DO NOT HAVE TO PURCHASE A LICENSE TO DISTRIBUTE THE RUNTIMES. Of course, they are distributed under a license but the license is free. I leave the comment below for its historical interest.
I think but am not sure that to distribute the access runtimes with your application you will have to have a license. I know that you used to get this license with an MSDN subscription and with Visual Studio Tools for Office.
END FALSEHOOD
Once you have the Access Runtimes, you can create BULLETPROOF runtime installations of Access apps using preconfigured installation scripts from SageKey.com.
Office developer tools comes with some deployment options but they are not bulletproof and I would NEVER distribute a commercial application using those...they just don't work. But the sagekey scripts absolutely ROCK. They work incredibly well.
All this presumes you want to widely distribute your app. If not (for example...you want to just deploy to your customers and you will have complete control over that) then you can use the download from Microsoft option mentioned above.
One last thing. Runtime access apps have to be VERY robust. You have to do error handling and automatic table linking very well among other things or you will spend all the time on the phone with your customers rather than selling/distributing software.
Hope this helps.
Seth
If you have the Developer version of MS Access, you can create an '.mde' file, which operates just like an .exe file as far as your user is concerned. Essentially, creating an .mde wraps a version of the MS Access run-time along with your database.
As long as you have done a decent job with your form design, the user really can't tell the difference between your .mde file and a .exe.
I haven't used the Developer version in a number of years, but if I recall, it is quite expensive. EDIT (It appears to be free these days).
Here is a link to a good FAQ on the topic. Much more up-to-date than my recollections from the past.
As far as bullet proof runtimes yes Sagekey is an answer. However another alternative is Albert Kallal's Inno script which checks to see if a version of Access is installed. If not it tells you to install a runtime version of Access. If installed then it continues to install your FE MDE and other assorted files.
http://groups.google.com/group/microsoft.public.access/msg/10e3fc9234660872?hl=en
Sample inno script which "wraps" the package wizard install into a single .exe
http://groups.google.com/group/comp.databases.ms-access/msg/4aa1b33a191bf1f8?hl=en
Deploying updates to your software in a Runtime environment for Access 2007
http://www.members.shaw.ca/AlbertKallal/RunTime/InstallExample.htm
The only scenario which it wouldn't handle well would be if the user does install Access or a different Access runtime on their system later. However if you ship your product in Access 2000 format the problems are minimized.
no it's not possible.
I don't believe it is possible. Sorry to say. You need the Access to launch and display the form.