Access Database Engine Redistributable

Comments

# Zac Woodall said on August 10, 2007 12:02 PM:

There was a post here asking for confirmation of this topic on UA:

http://www.utteraccess.com/forums/uaremgo.php?Cat=&F_Board=85&Thread=1466854&Main=1464030

Sorry, I accidentially deleted your post and there doesn't seem to be a way to recover it.  I've followed up on Oli's post in UA.  Here's the scoop:

For now there is no licenced way to redistribute the PDF/XPS addin with the Access Runtime.  PDF/XPS is a feature that requires Office Genuine Advantage (OGA) anti-piracy validation to download.  In order to get this OGA content, you need to have any valid Office 2007 product installed.  

From a technical perspective, nothing should prevent the runtime from using the addin.  From a legal perspective, we're working on a way to licence the addin in such a way that it can be redistributed by runtime developers, but it isn't available yet.  

Right now we think we can probably augment the license behavior here without updating the runtime bits, but nothing is set in stone yet.  Once we've worked through all the details, I'll post the result on the blog.

# SteveGoldring said on August 10, 2007 12:32 PM:

Hi Zac,

Thanks for further clarification on the PDF addin issue.

My post (the one you accidently deleted) was actually a general (but important) question about where developers should go to provide feedback on Access 2007 bugs, or, shall we say, behaviour that has changed from previous versions which worked beautifully and now fails miserably. I am not interested in whining, only in reporting problems which may require the Access Team's attention. I have a half-dozen Access apps in production, some of them first coded in version 2.0, which I am daring to transition to Access 2007.

-SG

# Zac Woodall said on August 10, 2007 2:22 PM:

Steve, if you've got stuff in your apps that worked well in past versions, but is failing miserably now, I -absolutely- want to hear about it.  We shouldn't be breaking solutions that used to work well.  Please send me a mail detailing the issue you're seeing, including instructions on how we can reproduce it internally so that we can investigate.

<edit>

BTW: in order to be able to send me email, you need to be logged in to blogs.msdn.com (accounts are free).

</edit> 

# Bill Mosca, Office Access MVP said on August 12, 2007 1:30 PM:

Zac

Concerning the Access 2007 database engine, it looks like this is a read-only. The JET engine is accessable for full access (writing/editing/deleting), is it not?

Why the change in the new engine?

# .Net Adventures said on August 13, 2007 10:35 AM:

In case you need to read or write from/to MS Office System Files (e.g Access 2007 or Excel 2007) .This

# clintc said on August 13, 2007 11:37 PM:

Bill Mosca,

The new engine does support writing, editing, deleting. The Jet engine is a system component and making changes to it ment making changes to Windows. The new engine gives us more flexibility to innovate in the codebase and ship updates via Office.

# David said on August 14, 2007 1:12 PM:

I have noticed a problem with access 2007 and I am not sure if it is a problem or I just need to change a setting.

We have several tables in the local db that gets saved as an accde for redistribution.  These tables are local work files.

All other tables are remote and connected via linking.

Our application works flawless if in accdb format

Once we run it using the /runtime option, we get a message that says "this database is read only, click here to save as if you wanna make changes"

well DOH, of course its read only, thats the purpoe of a runtime only option.  Users don't need to see that pop up - how do we get rid of that nasty little message that is totally unimportant to be displayed

Second, I noticed that it appears that the tables in the local accde file CANNOT be written to if your running in /runtime mode - Prob cause you have figured /runtime should mean read only.  And runtime simply means RUNTIME has nothing to do with read only.

Would appreciate some feedback on this so we can actually dist our newest version, which users have been waiting on due to the late runtime release.

# David said on August 14, 2007 2:07 PM:

In response to my previous post, the problem is not related to access, rather new windows vista security. We have for over 10 years installed our application in c:\Program Files\BizWizard cause thats where programs should be installed.  Well, you cannot do that with a accde or mde file anymore on windows vista because the c:\Program Files folder is a read only folder and a accde or mde file is read/write

So now, we have to go outside of normal standard windows conventions due to microsofts intelligent way of blocking writes the program files folder and install our software by default into c:\Bizwizard

isn't this a cute way to destroy the standard installations that most users expect to have.  Way to go Windows VISTA team.

# matthewcrow said on August 15, 2007 10:54 PM:

I had read that the new Access Database Engine and the new file format (ACCDB) was to be private to access and not available for developer (outside of Access). After digging around and testing I have found contradicting information. At one point, I thought that Jet4.0/Access 2003 was the end of the technology line for my products use of the MDB file, and we were going to need to look at SQL Server, but now I discover the AccessDatabaseEngine.exe distributable where I can install on any machine and get my product (VB6) working with ACCDB databases.

So, is the AccessDatabaseEngine.exe freely distributable to my customers, and can I migrate my products Access 2003 database to the new 2007 format and continue to use this technology ?

Can anyone point me to the licence and distribution information for the AccessDatabaseEngine.exe ?

# David said on August 16, 2007 4:26 PM:

Matthewcrow  DO NOT MAKE THE MOVE TO ACCESS 2007.  I highly suggest you making the move to competitor products, we are starting to.  This fiasco of access 2007 is a major problem.

I am not in the least bit happy at the moment, I finally get a code signing cert only to find that I cannot even sign my accde files.  they wrap them in an accdc file

I have 5 accde files that need to be part of a completed working application system.  I can even bite the bullet and sign an accde file with a code signing cert, but when Im forced to put it into a accdc file and then when its run, it exracts the file out and asks the user where to put it

SO MUCH FOR USING INSTALLSHIELD which is designed to keep components in places where they are expected to be.  

Oh hell, why not install windows os and give me the choice of moving all the windows files into whatever directory tree I deem I want to put them in and then when windows OS goes and tries to find them it can't

AMAZING - you guys totally bit the bullet on this one.  I cannot even believe you did this.

Now my support phone is going to ring off the hook, cause each time an accde file is called from one of the other accde's the users for the first time have to EXTRACT it and they can just extract it to whever the hell they want on the hard drive.

CLINT, sorry, Im pissed.  THIS IS THE BIGGEST FAUXPAUX I HAVE SEEN and would never have expected it to come from microsoft, let alone a division in microsoft that is writing a tool that is programming in itself

Who was the smart person who figured this was the way to go.

heres the choice you have left me with.  I have lost all faith and confidence in MS access team now.  RealBasic and MySQL here I come.

# M. David Matney said on August 16, 2007 8:49 PM:

Ok, so, in microsoft accesses intelligence, they make us go spend money on a code signing cert (in my case, I paid comodo $500 for 3 years cert)

So, I figure, I have to make my customers take a option to run the .accdc file which is signed from within access 2007 using the code signing cert obtained from comodo which is a microsoft recommended cert provider

so now I distribute the accdc files, and have a shortcut installe does nothing but execute the accdc file so that they user can select a folder to save the file into (which if they don't put into the correct folder, the whole application is broken) - but lets assume the user follows the instruction to the letter and extracts the accde file into the correct folder.

GUESS WHAT THE FRICK HAPPENS

THE DAMN MICROSOFT SECURITY MESSAGE THAT SAYS:

===============================

A Potential security concern has been identified

Warning It is not possible to determine that this content came from a trustworthy source.  You should leave this content disabled unless the content provides critical functionality and you trust its source

this file might contain unsafe content that could harm your computer.  Do you want to open this file or cancel the operation?

===============================

SO MR CLINT - WHY DID I SPEND THE MONEY TO BUY A CODE SIGNING CERT JUST SO THAT MY USERS COULD SEE THE SAME STUPID MESSAGE THEY SAW BEFORE I SIGNED THE ACCDE??

NOW IT DOESN'T TAKE A ROCKET SCIENTIST TO FIGURE OUT YOU HAVE SCREWED UP OUR APPLICATIONS FOR ACCESS 2007

THIS MESSAGE IS PERSISTENT AMONGST CALLS EVEN THOUGHT THE ACCDE FILE IS INDEED SIGNED WITH A CODE SIGNING CERT AS INDICATED ACCORDING TO THE MICROSOFT TRUST DOCUMENTATION

YES, IM EXTREMLY PISSED NOW  ESPECIALLY SINCE NOW ONE FROM THE ACCESS TEAM IS BOTHERING TO EVEN RESPOND TO MY BLOG COMMENTS

# M. David Matney said on August 16, 2007 8:51 PM:

I SPENT MONTHS CONVERTING CODE TO WORK WITH ACCESS 2007  I WAS EXTREMLY PATIENT WITH THE POSSIBILITIES OF THIS NEW VERSION.  I EVEN DEFENDED IT TO OTHERS.

AFTER MONTHS OF DOING THIS, WAITING ON THE RUNTIME, TELLING MY CUSTOMERS TO WAIT

I STILL CANNOT DISTRIBUTE MY APPLICATION DUE TO THIS CODE SIGNING ISSUE

# M. David Matney said on August 16, 2007 9:00 PM:

LASTLY, WHY IS IT THAT MICROSOFT DOESN'T HAVE TO SIGN THEIR PROJECTS?  NOTICE THAT ACCESS RUNTIME CAN BE INSTALLED WITHOUT ANY SECURITY ISSUES.  IS THAT BECAUSE MICROSOFT HAS PUT IN SPECIAL VALIDATIONS INTO THE OS TO PREVENT MESSAGES ON ALL MICROSOFT PRODUCTS?

About Zac Woodall