Access Developer Extensions 2007 Updates

>Integration with Microsoft Visual SourceSafe or other source code control systems What other source control systems?

I could not find any information about how to actually get Access objects to check/in out.

Any resources?

I would like to comment on the ‘Package Solution Wizard’: This issue has been raised here before. For example please refer to the post from 04 September 08, which dealt with the SageKey scripts for building runtime installations. blogs.msdn.com/.../sagekey-access-runtime-installations-discount-offer.aspx In that post someone wrote that he thinks SageKey is doing Microsoft’s job. I think that offering for free these developer extensions, which include the Package solution, is a nice gesture on the part of Microsoft and the Access team. That said, I don’t understand how the Package solution, as it is offered and has been offered for so many years, can actually be of any use to anyone. I may be mistaken here and I hope I am not saying something completely wrong or stupid, but from my limited knowledge and perspective, I would be surprised to learn that there is even one user, out of the purported millions, that found any use for it at all. Please correct me if I am wrong. The reason I am saying this is that this Package solution does not offer the ability do distinguish between files that will be overwritten during and install, and those that will not. You can expect that users of applications will be accumulating data. You can also expect that applications will need to be upgraded ever so often. How can you offer a user an installation package for an upgrade, knowing that it will overwrite all of the data she accumulated since the previous install? Perhaps you say build a separate package for a first install, and another for an upgrade? But I think that will not be fool proof and is too dangerous, because selecting the wrong installation package will cause the loss of all data. Also, it has been noted in the mentioned blog post above, that the SageKey scripts are “reliable installs that work on all supported platforms and maintain co-existence with other versions of Access.” Can that be also said for the Package solution discussed here? If not, then developers are still dependant on the exorbitantly expensive SageKey scripts. For these reasons am I to understand that this feature offered by Microsoft is only a “marketing feature” intended only to serve Microsoft when describing access to potential buyers, rather than being a real feature intended to serve real customers? Gilad

Hi Gilad.. I Vote for u brother... peace be with you! MS Access team can evade all the above issues because its the problem of the true ms access loyal developers. Information Workers (IW) which was the focus of the team esp on A14 used or will use the free Package and deployment tools.. Anyway, I and my clients are happy with THINSTALL.. AKA Copy And Paste...Goodbye Setup and MSI!

Gilad, It would seem that having a linkage resouce manager available for the developers would solve this problem of over writing data. I had rolled my own version of this way back in Access 2.0 days using a solution I found on Smart Access. I suppose I could port this solution forward, but seems like a lot of work and it seems that this should be built into the developer extension. If it is a Microsoft Best Practice to split the front-end from the back-end (which I certainly adhere to) then we need to be able to deal with this with our run-time solutions.

I noticed that I missed out on explaining something basic to what I was trying to say above. I forgot to explain the scenario I expect to be so common for Access users. In this scenario both the back-end as well as the front-end will be included in an installation package, along with other supporting files. The back-end will be marked as ‘never overwrite’ and the front end will be marked as ‘always overwrite’. This way if the user is installing for the first time, all files will be installed. If on the other hand the user has a previous version already installed, so that for her the install constitutes an upgrade, then only the front-end will be installed, and the back-end holding the accumulated data will remain intact. If the back-end also needs upgrading, that can be handled via the new front end. This way there is no need to separate between different install packages. One package fits all. I think this is the expected behavior that should be available in any installation package for Access, but as I wrote above, there is no such functionality available currently, rendering the Package and Deploy wizard useless, at lease for my purposes, and I can’t see for who it can be of any use. Erwin, you mentioned the Information Workers. Is that another phrase for ‘end users’? For me there is only one type of users: those that are willing to take the extra mile and invest the time and effort needed in order to learn how to use Access. Any way, I fail to see how any type of users will benefit from this wizard. If they are on location they will just copy and paste files where necessary, and avoid using the unnecessary package and deploy wizard. If they need to deploy to a remote location, then the same problems exist for them as for anybody else. And again, for remote deployment, the issues of compatibility with platforms and other existing versions of Access are also pertinent and must be handled smoothly. Gilad

Gilad,

Thanks for the great explanation of your scenario. I have shared your feedback with the runtime team.

Gilad, About Information Workers (IW) blogs.msdn.com/.../free-access-14-iw-workshop-microsoft.aspx Brother Gilad many thanks, what a great suggestions for the improvement of Package and Deployment Solution for Ms Access. Hope this time Access team will hear our plea.

I have been testing the latest Developer Extensions as I have two databases I wish to roll out to users, but to specific paths. Unfortunately the Package wizard isn't able to accept Subfolders as it displays an error about invalid characters in the install path - despite showing the correct path in the 'Example Install Location' box. Further, the logo file is treated inconsistently - on the first install screen it appears half way down and on the remaining screens (except the final one) the default logo appears instead. And a small niggle - why does the wizard have scrollbars (making it painful to fill in) when there is enough screenspace, and no maximize option as it is a dialog...