Access Blog Back Online

Glad to see you're still alive! Personally, I would appreciate it if you went through that list in REVERSE order. The last few items involve life or death decisions for project developement. The first half of the topics are mainly cosmetic. The people who read your blog are not newbies; we are mostly experienced developers here. These topics are critical:

Access Limits Upgrading to Access 12 Access in Mixed Environments Access and SQL Server

Access Developer Extensions *Installation, large scale Deployment, Automatic, hands-off updates

*MDB vs ADP vs .NET The other topics are very interesting and important (especially re ease of use for novices), but won't be as relevant to developers if Access can't handle complex multiuser scenarios and installation issues.

I agree go in reverse order! Here is what's most important to me. * Access and SQL Server * Access in Mixed Environments * Access Limits * Access Developer Extensions * Linking to External Data * Access on SharePoint * Customizing the New UI in Access

While true i.e many developers need to know this I think that the majority of users are not developers. I know that in my place while we build pro Access DBs users build far more of them than we do and I get the distinct feeling that developers aside that this is the market MS are aiming for. Well so be it. No mater how you dress up the interface via GUI, at the end of the day to build real applications and applications that work you still need to knwo table design, data types, relationships etc etc. Even to sue the new Many to Many tool you stioll need to know aht a Many to Many is and why you are using the lookup to hide this. This little "trick" by MS excapes me as users have to learn this theory anyway in order to make use of this hidden design tool.

So far Excel is far more common 'database' application for a typical end user. I'm yet to see a user who ever tried to create its own database with Access... maybe version 12 is going to change that. But whether a user succeeds in building a viable business solution, or turn to a developer to materialize it, it's certainly going to be of interest for other users in this new reality. So here's the topics I'd like a further info on: 1) Access as a RAD tool for SQL Server 2) Converting databases to SQL Server

3) Deploying Access databases with SharePoint Services

4) Web reports and forms

5) Secure deployment and restricted user access

6) File sharing issues over peer-to-peer networks

7) Access SQL language enhancements (if any) Also, I wonder if Access 12 over Sharepoint could be treated as a kind of low-cost version of the SQL Server, but customizable by end users?

Hi ! I don't think that a lot 'users' watch this blog.

Maybe you can make a poll how access is used from the visitors. - drag&drop and assistances, only one mdb

- makros, querys in design view

- all logic in VBA and dynamic SQL or

- better Excel

- small department specific applications

- just as RAD for protoyping

- enterprise business apps maybe ms did something similar as marketresearch already ? thomas

I would have to agree with DmitryKo. I watched the Access presentation from the PDC (BTW...very impressive!) and it seems that this idea of users creating their own databases is still a prevalent one. In reality, this just doesn't work. I've been doing consulting, mostly with Access, for 13 years now and I have yet to see a database created by an end user that wasn't...well...a mess! OK..maybe the out-of-the-box templates aren't a bad idea. But anyone that needs a databasee app for any real world purpose will never be happy with a template application, IMO. Erik, the question of security is still a hanging one. Seems that the question was never directly addressed form the blog of a few months ago. Will there be user level security? If so, will it still follow the SYSTEM.MDW type of model, and will the encryption be strengthened so that it can not be hacked? Thanks, John

I totally understand the desire to invert the order and cover Access 12 from the inside out. There are 2 key things that keep me from doing this. First, we're really serious about making the product easy enough for end users, and it will be hard to understand the investments we've made in the guts of Access unless we've gone through the rest of the app. I really will get to the innards of Access, but it will make much more sense if I can set the context first. Please just be patient with me. Second, there are actually a lot of folks that read these blogs who aren't developers, and I need to get them up to speed as well. Again, please stick with me and we'll get to the details. On the security front, user level security is covered in the October 19th post on Security. In short, we don't recommend using user level security in Access where significant protection is required. That is a great place to use SharePoint or SQL Server.

> Wow, I really don't understand that position. I come into an environment where the customer need might be something like "I need a department level app for 10 users, and it must be secure since we are tracking customer investment information". Access can easily handle the requirements, but now I have to tell the customer "Well you have to invest in SharePoint or SQL server, hire a installation specialist and probably an administrator". It just doesn't make sense! What it boils down to is just to have a STRONGER encryption for passwords in SYSTEM.MDW; this does not seem like an unreasonable request. Now I can fulfill the customer needs, make it economically feasible for them, with no additional and unnecessary overhead in resources required. 99% of the work I have done in Access have been these types of applications. Why should we have to force a customer into something that just isn't required for the particular need? Its the proverbial using a canon to swat a fly approach. I have no objection to having that functionality on Access, in fact I think its great. However, if there is an emphasis on making Access an end user tool, then do NOT require a big and expensive back end for it to be functional. Thanks, John F

maybe split the blog to 2.. one for newbies and one for developer

Erik, Thank you for getting this blog going. The list of subjects to be covered looks really good. So far I have been really impressed by what I have seen. Truly I have. I do still fear what is happening on the security side though. Even though SQL Server Express is a bit easier than previous versions of SQL Server, there is still a big jump involved in using it instead of ACE/Jet. Please do act on the concerns expressed by some of the developers here. Expecting us to use Sharepoint or SQL Server to get any reasonable security is a big fault.

I agree wholeheartedly with Alan. I too am looking forward to the new release. Many of the new features look very promising. But I know that in most cases, based on my past experience (I've been developing Access applications since 1.0), I will NOT be using Sharepoint or SQL for my apps. Its great that these options are available, but I think its too stiff of a penalty for an end user, or customer for whom I might develop an application, to require SQL in order to have decent security. Please...PLEASE...shore up local Access security. I think the biggest issue is with SYSTEM.MDW. If the passwords there were strongly encrypted, I think it would solve the major problems in the security model.

Its great to have the new GUI features that are comming with the new version. What about the size of the database that is to say is it comsuming more data storage.

Previous versions has 2 gigabytes minus the space needed for system objects. I am keen to know whether MS Access 12 accomodates the date capacity and consumes more data storage space using the new GUI. I would make a sincere request to increase the data storage capacity atleast considering two factors Small Business and a effective and effecient use of MS Access 12 for the same.

Your statement that you have not increased the 2GB size limit of an Access database has me very disappointed. As a developer I would have hoped that MS had increased this limit in Access 2007. Outlook personal folders mailbox store used to be limited to 2GB but MS increased this to 20GB with Outlook 2003, why can't the Access 2GB limit be similairly increased? At least 20GB would give some breathing room, 2GB is way too tight nowadays.

I think that 2 GB is all you would ever care to try to push through the JET Engine. If you're storing data in Access, you're going through JET to get it. It's just not that powerful an engine. I don't know your motiviation to stay in Access, so it may be compelling and that's that. I can't help thinking that by the time you're trying to move around in more than 2GB of data it's time to be in SQL Server. One tip from the old days: When I had an application that stored more data than Access could handle (must have been Access 2 or 97) I finally settled for splitting the data tables apart, storing each large table in a separate MDB. I lost delcared referential integrity, but I also lost the size limit that was killing us. If that's an option, you could run integrity checks through a middle tier that's actually inside your MDB or MDE. I'm curious to know, why the drive to try to deal with more than 2 GB of data within Access (as a data container)?

Agreed that the 2 GB limit is quite painfully obsolete these days. How strange: in the new MS Office, if you're working with small amounts of data, you use the database, but if you're working with multiple gigabytes, you use the spreadsheet instead (limited only by OS-available memory, which with 64-bit Windows means 128 GB). This isn't right. It's very disappointing to know that I'll need to forgo using Access except for projects where there's no chance at all of wanting to store a lot of data, which want is common when doing data logging and analysis, even on a standalone PC basis. Excel is growing up, albeit very slowly (breaks the 64K barrier in--what year is it??); I wish Access would too.