Failure creating Access database from TFS 2010 - ms-access

I have an Access database in source control on TFS that I need to pull down onto another machine (XP, Office 2007). I have the Team Foundation Server MSSCCI Provider 2010 installed and I can successfully see the source. However, when I try to have it created it fails, giving me this error:
Failed to create a new database on a Team Foundation project.
Any idea what I've done wrong on this machine?

I think the solution to this was that I had sent the database up to TFS from Access 2010, but was trying to pull it down to another machine with Access 2010. I thought the two versions shouldn't matter, but sending it up to TFS in Access 2007 and bringing it down in Access 2007 and Access 2010 appeared to work.

Related

Using both Access Runtime 2013 and Access 2016 on one computer

I have here a specific application I am forced to use. This application uses Access as data storage.
This application is older and was once developed for Office 2013. Our company computers have now Office 2016 installed, with Access 2016.
After the installation of Access 2016 this application stopped running. It hangs immediately after start.
So i installed Access Runtime 2013 and application first worked fine. But as soon as I open Access 2016, there is a repair run installing something in the background and application again stopps working. After executing Repair on Access Runtime 2013, it works again until Access 2016 ist again opened.
After checking the dump of this Application I see that after running repair of Access 2013, Office15-DLLs are used. After starting Access 2016 and repair run, Office16-DLLs are linked and application stops working.
All those repair runs take minutes, so they are very annoying, as I often have to switch between both applications.
Is there any other / better way to handle it? I tried to set Runtime 2013 into the PATH of my application, no changes. Can I somehow force the application to use Runtime 2013 instead of Access 2016?
Thanks!

Word 2016 mail merge missing 15.0 Access Database Engine OLE DB Provider

When running an existing mail merge I receive an error in one of my machines: Class not registered
No real indication of what is not register
The only thing I can find different between working and non-working machines is in the Data Link Providers. in the non-working machines I am missing 'Microsoft Office 15.0 Access Database Engine OLE DB Provider'.
I assume these documents were created using this provider and my trouble machines does not have it.
Any tips for how to get it?
Thanks!
The solution was to install the Access 2013 Runtime. This made 'Microsoft Office 15.0 Access Database Engine OLE DB Provider' available in Word 2016. Although the default application to launch .ACCDB became the runtime, so I needed to change the default back to 2016.
Here's a link to the 2013 Runtime: https://www.microsoft.com/en-us/download/details.aspx?id=39358

Creating an MDE 2003 file from Access 2010

I run MS Access 2010 on my home PC and I've been building a database for work.
Most workstations at work don't run Access to build databases, but they do allow us to run MDE files for applications already built.
I saved my database as a 2002-2003 database and then published it as an MDE file. All worked really well. I tested the MDE file on my PC at home and the automatic re-linking to the back end db worked and the database popped up. Awesome.
The problem came when I tried to run it on the workstation. It came up with an unrecognized format and suggest I change the version on the database.
So, back to the drawing board. I did some research and from all indications from other forums and sites, you cant build MDE files for 2002-2003 databases using Access 2007 or 2010, even though the option is clearly there.
Suggestions were to load Access 2003 to the PC an build the database using this. OK, did that, imported all of the items from the 2003 database created in Access 2010 to a blank db created in 2003 and I get nothing but errors. Incidentally the database was originally build from and access 2003 database at work! Unfortunately, I no longer have access to that particular workstation.
So that's the dilemma. The question / discussion im after is how to resolve this and get the database, preferably from my office 2010 suite into a standalone system of some type working from a Windows XP workstation at work.
I need to find a way to be able to build these tools at home and use them at work. BTW, upgrading the workstations at work is not an option. believe me the organisation is too large to even consider a change like that, WAY too much bureaucracy..
As mentioned in one of the comments to your question, if you are targeting an older version of Access then you should be doing your development in that version, not a newer one. Even though Access 2010 allows us to create an .mde file that is in the Access 2003 file format, it may actually create an .mde file that Access 2003 cannot understand due to the contents of the file.
The situation is analogous to the problem of making certain modifications to an Access 2007 database in Access 2010+ that render it unusable by Access 2007. Even though the file format is still "Access 2007 or later", Access 2010 may create database objects within that file that Access 2007 cannot comprehend. Depending on the actual objects involved, Access 2007 may simply ignore what it doesn't understand, but unfortunately in some cases Access 2007 will just give up and say "Unrecognized database format".

Access 2013 Web App linked to client-side Access 2007 database

I have developed a access 2007 database that is hosted on the clients server. They input data 24/7 in house, and enjoy the fast speed of the local connection. However, they are now wanting to view this data on a mobile device. I would like to be able to create a new Access 2013 web app, and have my current access 2007 database transfer data to a hosted server somewhere, where the access 2013 web app will run from. There won't be any need to add/edit/delete data from mobile, just view, so that saves me a lot of trouble with having to convert all my vba. I just have no idea how to go about this, or if it is possible. If I use a hosted sharepoint server, can I add my web app there, and be able to transfer data to the server to view?
Unfortunately Access 2013 web uses SQL Azure, and starting with Access 2010 is when support for Azure was introduced. I not at all sure you can thus use Access 2007 to connect to a 2013 web database (you should be able to use 2010 or 2013).
I think in this case you might consider just building a simple asp.net web site and then have Access 2007 send some data to that site (assuming the site allows external ODBC connections – these are becoming harder to find these days).
As I alternative I suppose you could upgrade to Access 2013, and for existing desktops deploy the FREE 2013 runtime. This should in theory allow you to keep your existing application, and also connect to the 2013 web application you publish. You have to sort up the users permissions here.
So while the Access client(desktop edition) can link to published Access web applications, I don't believe that Access 2007 can be used since it does not have support built in for using SQL Azure like 2010 and 2013 does.

Microsoft Access version rules when using TFS Source Control

I have a Access 2003 database that I want to store in source control on TFS2010. I'll be using the Team Foundation Server MSSCCI Provider 2010. Are there any rules for which versions of Access can create a database from that source? It's possible that Access 2010 and 2007 will be used to edit the source control. I'm curious as to if I should limit the versions of Access touching the source code to just a single version of Access.
The site of MSSCCI states to support Access 2007: http://visualstudiogallery.msdn.microsoft.com/bce06506-be38-47a1-9f29-d3937d3d88d6
On the same site, two other references from users can be found. One is stating that this version also works for Access 2003. Somebody else is experiencing that this version of the MSSCCI does not work for Access 2010.
A save bet would be to start your efforts with Access 2003, or if possible better with 2007. At least do an experiment with saving some 2003 stuff and opening it again with 2007 and vise versa. In time, I guess that support for Access 2010 will show up and you can continue from there on with newer version.