Prev: Update query annex passtrough
Next: report + textbox color
From: Albert D. Kallal on 9 Jan 2010 21:39
"Bob Alston" <bobalston9(a)yahoo.com> wrote in message
news:ag62n.3754$%P5.2195(a)newsfe21.iad...
> Take a look at this thread for answers to verious questions about security
> settings for users accessing an Access 2010 app to download to their PC
> and run under Access/windows.
>
> http://social.technet.microsoft.com/Forums/en-US/sharepoint2010general/thread/13a3b9c0-3fb9-4ff0-b725-145d5e482473?prof=required
>
> Note that with this setup, you cannot have the equivalent of an MDE

(note: I using the term mdb and mde here for clarity, but in fact we talking
about an accDE and an accDB).


Why not just publish an mde then ?

I mean, if you going to publish a mdb file for distribution, then you have
an mdb file and that is your intention. I think for what, about 18 years of
ms-access an mdb file are able to be modified by users. Why would you expect
this to change? For what reason?

You can certainly publish an mde file to access services, and the resulting
download can not be modified by the end users. (well, no more or less then
mde always been). However we talking about VBA forms that are linked to
SharePoint tables here.

I mean is quite simple that an published mdb is going to be modifiable by
users as that is how they always worked.

Now, I not played much with testing and publishing mde files. However, you
can publish them and the end results are NOT able to be modified by end
users. I think the "gray" question here would be how to send out new
modifications using this approach? I have not played with this idea much,
but you could likely import new forms from the non published mde (accde). We
just have to play with this a bit more.

On the other hand, you can always distribute an NON published accDE file
that has the tables linked to SharePoint. It is a question if you want or
ARE going to use *web* services for the distribution or not. You don't HAVE
to use published web services application for distribution methods here. You
can just distribute the mde file to your end users.

As I see this now, the only trick or question is how to get new forms etc.
into that mde that has been published to web services.

Perhaps one has an design master that we import those forms from, I just not
played with this enough to figure out what approaches will work.

However, at the end of the day, you still have the option to distribute an
mde to users that has tables on SharePoint.

For years, I had an built in web based update system into my software, and
who knows, I likely continue to use that method. On the other hand, if you
talking users in 100% browser based, then they not running ms-access local,
and they don't even need ms-access installed in that case..

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKallal(a)msn.com


From: Albert D. Kallal on 11 Jan 2010 02:35
"Bob Alston" <bobalston9(a)yahoo.com> wrote in message
news:AKp2n.9451$Ef7.4431(a)newsfe07.iad...


> I am focusing on the capabilities of Access 2010 and Powerpoint 2010.

I think you mean SharePoint..not PowerPoint! Unless I am really
am misunderstand your posts? I mean, you should not be
surprised that an accDB (or mdb) which has been modifiable by
users for about 18 years and is how ms-access has worked
from day one is an surprise? I not sure why a link that
shows that accDB files can be modified by users is really
big news here?

I guess I very much missing the news in
that post + link of yours?

*.accde can
> access data found on an Sharepoint 2010 server.

Yes, so can accdb also. As I mentioned, you can publish
an accde file to share that is linked to share data.
Users will not be able to modify that file they download
(but we are talking about VBA FORMS..not web forms..right???).

The "trick" or question is then how to update new editions of
this published accDe file. We have to play with this to see
how we can do this.

Keep in mind however that when using accde's, the goal is NOT
to allow users to update parts of the application. This has ALWAYS
been the case when using replication before SharePoint for
deploying applications. So, given past history, it likely don't make
a lot of sense to try and update parts of publish accde file
when they not for that purpose. However, as mentioned, some
testing might reveal that we can use this approach in place
of re-downloading the whole accDE file again (which is what
I recommend here). Remember, updating an application front end
is an DIFFERENT problem then that of sharing the back end
data which can be placed on Share. You can distribute
an non published accDE file that is linked to that sharepoint
back end data. You are NOT forced to use a web published
application in this case.

> 2) The ability to use sharepoint 2010 server to a) download the app and b)
> automatically update the app.
>
> I would enjoy hearing from others who are testing out the
> Access/sharepoint 2010 capabilities to do these things.

The following video goes through most of the scenarios here. In fact, they
even go though an example in which your data is a CLASSIC split back end
system where the data not even on share.


Managing Access Databases with SharePoint
http://blogs.msdn.com/access/archive/2009/12/02/the-access-show-managing-access-databases-with-sharepoint.aspx

The above is gold mine of examples and ideas....

If you not seen the above..watch it....perhaps more then once...as it have
an LOT of info packed into it...

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKallal(a)msn.com


 | 
Pages: 1
Prev: Update query annex passtrough
Next: report + textbox color