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.
Related
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".
We have a 2007 Access database application that we would like to deploy to a large number of users at various sites with different versions of Access (some without an install of Access and just instructions to install the Access 2007 Run Time) for a data collection effort. We were planning on deploying it as an ACCDE file with compiled VBA code - we noted that users with 2007, 2010 and 2013 could open this file. However, during testing, we discovered that at least one of our user's computers had 2010 installed but, the 64-bit version of Access/Office and we received the following error message upon trying to open it:
This database was created with the 32-bit version of Microsoft Access.
Please open it with the 32-bit version of Microsoft Access.
We are now looking for some alternative options to account for this unforeseen compatibility issue. The application was developed on a 32-bit version of Access 2007.
If we were to deploy the ACCDB file, instead of the compiled ACCDE version, would 64-bit version of Access still be able to run it?
For all years 2007-2013?
Also, would users with just the 2007 Access Run Time still be able to open just he ACDDB file?
If we were to deploy the ACCDB file, instead of the compiled ACCDE version, would 64-bit version of Access still be able to run it?
Generally speaking, yes. Provided that
there are no 32-bit third-party ActiveX controls being used, and
calls to the Win32 API (if any) are pointer-safe
then the 64-bit versions of Access will be able to recompile the VBA code automatically when the .accdb file is opened. (They can't do that with the .accde file because the .accde file does not contain the VBA source.)
Also, would users with just the 2007 Access Run Time still be able to open just he ACDDB file?
I would expect so, particularly since Access 2007 was still 32-bit only (as I recall). Of course, the best way to know for sure would be to try it and see.
At work I have a very basic MS Access 2010 database (tables and basic forms, no special coding). At home I have Access 2003 on my XP michine. Is it possible to be able to open and work on the 2010 DB in my 2003 version? Please don't start making the suggestions of upgrading. I have an older machine with XP (yes, I know XP is no longer supported by Microsoft), but at this time don't have the money to buy a new system and new software. Just need to know if (and how) can I work on 2010 version in 2003 version.
Thanks
Kenny
The file format used changed with Access 2007 from using.mdbto.accdband in order to open the file with Access 2003 you would have to save the file in the earlier format. This page has information on how to do this: Save an Access 2010 database in an earlier file format
I inherited an access 2003 ADP file which uses sql 2000 as it's data source. This is my first access maintenance project and not thinking about the issues involved simply opened it in access 2007 on my dev machine. It of course worked and I proceeded to do the work requested.
I have completed the work and presented the file to the client, which he opens in access 2003 and proceeds to receive several errors, all related to variables not being declared. It is at this point I realize that none of the code files have Option Explicit set. I look at the project in access 2007 again - no errors. The behaviour is as if access 2007 is respecting the Lack of Option Explicit and working as expected, but access 2003 "thinks" Option Explicit is set, even though it never appears in any code files.
I realize I could just re-do the work using only access 2003, but that would be more time-consuming than I'd like.
Weird problem - I can't see how Access 2003 would check for explicit varible declarations without any Option Explicit. Something else must be going on.
Can you reproduce the behaviour on your machine using Access 2003?
How about you actually declare your variables? You should have Option Explicit set regardless.
UPDATE:
Since the goal is to try and get the Access 2003 mdb (saved from 2007) working. I would try one more thing.
Using Access 2003 open the mdb with the /decompile switch
Make a backup of your mdb
Open your mdb (hold the SHIFT key down to stop any code from running) via a short cut: msaccess.exe database.mdb /decompile
Open a module and compile your app
Save and close Access
Open again (SHIFT again) without decompile
Compact and repair database
close Access
This isn't going to help you much, but I learned very quickly when one of my clients switched over to Office 2007 that I should NEVER work on a 2003 db in 2007 and then try to run it in 2003. Developing in 2007 then converting to 2003 doesn't work either. Developing in 2003 and then running the 2003 db (without conversion) in 2007 works pretty well. Most of the time.
A possible answer for the second part of your question:
1. Convert your 2007 db to 2003 format.
2. Open a new empty db in 2003
3. Import all objects from the converted 2003 db. Recompile, and try it on your client's machine.
I had this problem too. I am 2 years into developing an Access 2003 front end that connects to an SQL backend. I started to use Access 2007 thinking all I had to do was save in 2003 format and all would be well.
Not so. All my users still using 2003 reported problems.
The problem was easy to solve in the end. I didn't actually use any 2007 features and so all that was changed was the library references. I had 2 missing references to the Word and Excel 12.0 libraries, which were automatically included just by opening the database in 2007.
Took those references out and I was able to 'fix' my database without having to revert back to an earlier version.
My question about the reconfiguration delay when switching between Access 2003 and 2007 the comment was made:
Btw, you can't avoid the reconfiguration between Access 2007 and earlier versions. Access 2007 uses some of the same registry keys as earlier versions and they have to be rewritten when opening Access 2007.
If this is so then is it actually safe to be running/developing databases in both versions at the same time? Do the registry changes affect the operation of Access once it has started up. For example recompiling/saving changes to objects?
It works most of the time but it's not perfectly safe, which is why Microsft refuses to support multiple installations of Microsoft Office on the same pc. The recommended solution is to install a virtual machine and install the second Microsoft Office version on the virtual machine. Then you can switch from one version of Access to the other without them interfering with one another (and no switching time wait!)
Microsoft offers a free download of Virtual PC 2007 in both 32 bit and 64 bit versions:
http://www.microsoft.com/downloads/details.aspx?FamilyID=04d26402-3199-48a3-afa2-2dc0b40a73b6&DisplayLang=en
Here's the service pack:
http://www.microsoft.com/downloads/details.aspx?FamilyID=28c97d22-6eb8-4a09-a7f7-f6c7a1f000b5&DisplayLang=en
It is perfectly safe, I have done it very often (both running and developing). As soon as you open a database in Access 2007, some extra properties will be added to the database. However, this is done in such a way that you can still open the database safely in Access 2003 at a later time.
We also have databases installed in a multi-version environment were different people use the same backend, with the front end opened in Access 2003 or 2007.
It seems to me that the instance of Access you open will inherit the registry settings at the time it is open. So, if you open A2K7, you'll get the registry settings that it writes in its "configuring Office" procedures. If while A2K7 is still open, you open A2K3, it will reconfigure the registry settings and inherit those for its session. This will have no effect on the already-running instance of A2K7.
The only possible exception would be if there are some registry keys that the "configuring..." process changes that Access doesn't read upon opening, but later in the session. I have strong doubts that MS would ever design things that way. Professional Access developers been dealing with this kind of thing since MS introduced the MS Installer (first seen by most people with Office 2000), and the A2K7 issues are only slightly worse than with previous versions (though on Vista, it's more complex because of the way Vista handles registry changes). The fact that MS gets the vapors over contemplating multiple versions of Access on a single PC does not mean that it's actually dangerous -- it shows only that they don't want to devote resources to supporting that scenario.