Prev: Why couldn't exit the MS ACCESS program
Next: Interacting with Website
From: Salad on 8 Feb 2010 16:15
I was looking for something on Access 2010 and came across this link.
http://technet.microsoft.com/en-us/library/cc179181%28office.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/.
From: Banana on 8 Feb 2010 22:17
Salad wrote:
> Isn't Sharepoint secure?
>
> It's a beta product and any books on it won't be out till sometime this
> month...Access in June.

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.
From: Salad on 8 Feb 2010 22:55
Banana wrote:
> Salad wrote:
>
>> Isn't Sharepoint secure?
>>
>> It's a beta product and any books on it won't be out till sometime
>> this month...Access in June.
>
>
> 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.

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.

> 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.

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.
From: Banana on 9 Feb 2010 07:54
Salad 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 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.

> 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.

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.

> 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.

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.
From: David W. Fenton on 9 Feb 2010 16:39
Banana <Banana(a)Republic.com> wrote in
news:4B70D3CC.8030109(a)Republic.com:

> 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.

There is no way to use a database password to build a secure Access
application. The db password is not security at all.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
 |  Next  |  Last
Pages: 1 2 3 4
Prev: Why couldn't exit the MS ACCESS program
Next: Interacting with Website