I was looking for something on Access 2010 and came across this link.
http://technet.microsoft.com/en-us/l...ice.14%29.aspx.
It lists some of the changes coming to 2010.

Gone: These might not affect many. But for the few...best be prepared.
1) MSCal. There's a new calendar control in 2010 that replaces it.
2) The Snapshot Viewer is gone. Use PDFs instead.
3) Replication Conflict Viewer is gone.
4) Data Access Pages.
5) Support for Lotus 123, Jet2, and something I never heard of b4...Red2.

New:
1) Export to pdf or xps. Instead of requiring an add-in, it's part of
the system. That'd be nice, expecially if one could add attachments to
emails of any type; txt, xls, doc, pdf, zip, or any document time. But
I see no mention of that.
2) Share a database on the web. That seems to be the big news.
3) Connect to a Web Service as an external data source. I haven't seen
any mention of that feature.

Improved/Changed:
1) Little backward compatability between A2007 and A2010.
2) Enhanced security. The push is for Sharepoint.
3) SQL Server 2008 data type support

This issue wasn't mentioned in the above link but is of
importance...speed. It was addressed in at
http://blogs.msdn.com/access/. The first article in the link contains
some graphs. I have no idea what the timeline is; milliseconds,
seconds, or minutes...I guess (s) means seconds but that's a guess. But
I like their statement "Our goal for Access 2010 was to make connections
to SharePoint lists nearly as fast as local tables." If the graphs are
accurate in real life, A2010 is going to blow away A2007.

I also saw this site that Bob Alston and others might be interested in.
It a Microsoft Access/Sharepoint 2010 hosting site and they're
advertising their stuff at http://www.accesshosting.com/.

Salad <salad (AT) oilandvinegar (DOT) com> wrote in
news:fOOdnfANNYlo4-3WnZ2dnUVZ_tSdnZ2d (AT) earthlink (DOT) com:

This is a faux feature. It's a checkbox item. There is nothing in
Access that constitutes real database security. This is all about
Sharepoint (i.e., not Access) and the Trust Center (which is a pile
of crap that is there for nervous nellies in the IT department who
have absolutely no comprehension of how an Access app is supposed to
work).

There is no enhanced securithy in Access 2010. Period.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

David W. Fenton wrote:

It's a beta product and any books on it won't be out till sometime this
month...Access in June.

Salad wrote:
But David's point is that it's not Access'x security. We're just moved
from one security model to another.

If we wanted to talk about Access security we should be looking at the
fact that 2007 enhanced the encryption (I can't remember if 2007 did
encrypt + database password in one go as is the case with 2010), and it
is possible to further enhance the security by modifying the API it uses
for the encryption.

But to claim that we have better security because we can use Sharepoint
isn't really that different from the fact that we always could do the
same by storing data in a server-based RDBMS and using their security
model. In a way, it's red herring because we should be asking whether
the security within a pure Access solution has improved.

Banana wrote:
I didn't see the purpose of the encryption or perhaps I should say I
wasn't enthused by it. Encryption didn't occur by table but by
database. For example, a HumanResource table would be unencrypted if it
was contained in the database when a user entered the correct password.
I considered that of limited use in protecting sensitive data.

I'll leave that to the experts. If the other method could have been
used for easily publishing of an Access database on the web then I've
been Rip Van Winkle.

The way I look at is...I don't care much for the data. My concern is my
code and the manipulation of data. Now the company I work for word
would disagree and consider the data is most important, the code
secondary. The optimum is protecting both code and data.

I believe the world is moving away from the desktop and to the internet.
So if Sharepoint can be the protection on the web, and if it can do a
good job, and Sharepoint is the tool to provide security, that's A-OK
with me.

I am not aware of the security model in A2010, or Sharepoint. I am
aware however of the lack of knowledge most people have about
security, especially encryption and access control. I would simply
like to point out that security is not a product, nor a feature, but
is achieved by correct application of design methodologies.

I would be inclined to believe that any security offered by A2010 or
Sharepoint is probably rubbish - but that is just my opinion. If you
really want to secure your data, and your code, then you need to
implement this in code at design time. It takes a lot of work to do
this in Access at this time, but it is possible to achieve both secure
data storage and access as well as code storage. I would imagine that
only a few people using this forum could do this properly.

Please forgive my words on this if they seem harsh, I certainly dont
mean to offend anyone. Security is a topic that I am passionate about.
That being said I am happy to share what I know if anyone wants it.

What I find interesting in A2010 is the ability to work with web
services natively. This would mean that you could work with Google
Docs / Apps for example, and host a completely online and free
database application (client on local machine, tables on the web). I
read somewhere that Google will also be opening up direct access to
their BigTable database system for Google Apps and developers. I would
imagine that with careful design it would be possible to generate a
'generic' front end application that implememted security the 'right'
way and yet provided completely customisable features for applications
- and keep the data online and safe. Now that would be a framework
worth building and sharing (IMO).

Cheers

The Frog

Salad wrote:
I agree also. I do understand why they took ULS away (it was rather
ineffective at providing the real security) but the thing ULS had that
any other DIY solution didn't - it worked at database engine level
rather at the code level. Lower the level is usually better, and ULS was
always 'on', which made a lot of sense.

With Access files needing different level of security, the solution
(staying within Access only) would have been to split sensitive data
from not-so-sensitive data and place them in different folder with
different permission levels, but that usually makes for unnecessary
complexity, IMHO.

Um, I wasn't talking about publishing to web. I'm talking about the
security. When we publish to the web on Access 2010, we are basically
converting the tables into Sharepoint lists, forms & macros into
Sharepoint web parts... All those are now Sharepoint objects managed by
Access 2010 and they do use Sharepoint's security which I think is much
better than any file-based security. However, this doesn't actually
protect Access objects (e.g. client forms, VBA, whatever) should you
download the file from Sharepoint. I've discussed this at a length in
response to Bob's question about security for Access 2010/Sharepoint in
this newsgroup.

Sure. Code is usually the easy part. One advantage of using mde/accde is
that it's much harder to decompile a mde/accde than it would be to
decompile an .exe written to machine code or to .NET's CIL. So code is
very easy to protect.

In the same thread, however, I've pointed out that accde seems to be of
limited use in context of web database because macros are still
editable. I've yet to find a way to use Sharepoint's security upon those
macros. I can deny the access to downloading the file and offer only
rich client database for download, which is why I tend to agree with
David that there's really not much new security to Access.

Data, OTOH, isn't even protected at all by mde/accde. It still can be
linked, queried, and modified. A necessary condition, I suppose if one
were to have legitimate need but there's just no way to prevent
illegimiate use short of moving the data out from Access files into a
server-based RDBMS (or Sharepoint as well) and thus using their security
mechanisms to manage the permissions to data at object or even at
row/column level.

The Frog wrote:
Agreed.


Access 2010's security has not been changed compared to 2007. Sharepoint
security is far preferable only because we're no longer dealing with
files, which by nature will be problematic to secure. This is no
different from moving data into a server-based RDBMS & configuring its
permissions accordingly.

IMHO, implementing security at code level is not really the right way.
Yes, it can be used to good effect (and indeed I do this), but the
security should be at the lowest level and that's usually the database
engine's level. One thing ULS did right was that it was always "on".
There was no way to bypass or circumvent or turn it off. This is similar
to what many server-based RDBMS does - always run by security mechanisms
for every data access requests. Unfortunately, ULS had many other
problems, the main thing being that we had no daemon to shield users
from touching the data file directly. It was by necessity that we deal
with files so it will always be problematic.

At least in 2007, they combined the encryption & database password and
used the database password as key (meaning it's not stored on the file,
if I've understood it correctly) which was a step in right direction and
could have been used for ULS as well and because 2007 now uses external
APIs, it is possible to change the algorithm used to encrypt the file.

But what I think they really missed the point was this: If the security
was file-level, why even bother with database-share password if it could
have been in a folder with appropriate permissions and thus is much more
secure without the extra overhead of encryption?

How is that different from the approach we've always had available to us
by using server-based RDBMS? I do think the ability to connect to web
services natively is a good feature but it's still same solution in
terms of security by different name, I would think.

On Feb 9, 8:15 am, Banana <Ban... (AT) Republic (DOT) com> wrote:
Both are needed. Although my preference would be to store strongly
encrypted data (using code) over protecting the database engine, it's
usually true that only some of the data in a database is sensitive.
That data can be encrypted as strongly as desired and stored, while
the rest can rely on the relatively meager encryption of the database
engine. The lowest level is the data itself.

James A. Fortune
CDMAPoster (AT) FortuneJames (DOT) com

Salad <salad (AT) oilandvinegar (DOT) com> wrote in
news:mKqdnT7W1vTLTO3WnZ2dnUVZ_sGdnZ2d (AT) earthlink (DOT) com:

That's not Access.

If they enhance SQL Server security, that is not an enhancement to
Access's security, even though it means you could build an Access
app that takes advantage of SQL Server's enhanced security.

There is no security in Access from a data point of view (database
passwords are a child's toy -- even if the encryption is strong,
it's not useful for an actual application).

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/