Let's say we have an app published to the web writtem by AlbertCo. He's
invited me to use this app for viewing AlbertWares, the products he
sells to. Salad has Access2010 sitting on his desktop and he wouldn't
mind having the data in Albert's tables.

Can Salad then open up Access 2010 and link to the tables on Alberts
site? Can he see/review the data there without going thru the web app?

Not if the app is written correctly. In the end it depends on how it
was written. I dont think you could ever use a linked tables scenario,
but you could probably use pass through sql as a scenario. Basically
you are looking to see if you can gain the necessary info to access
the BE from the FE (web interface). If done properly this is a no.

The Frog wrote:

OK. Let's say the app is going to be running both locally and on the
web. Are they disconnected from each other? Wouldn't the local folks
be linked to the tables on the Sharepoint server as well?

Ahhhhh, I see. Sorry Salad, I thought you were meaning a PHP or ASP
page on a web server. I dont know about Sharepoint. Maybe there is a
Sahrepoint guru having a read of this. I am also curious to know the
answer to this as Sharepoint is coming into my office at the end of
this year (supposedly).

Cheers

The Frog

"Salad" <salad (AT) oilandvinegar (DOT) com> wrote

Yes, if you have permissions and a logon.

And, if the site is setup for anonymous (no logon required), then again you
would be able to link to the tables on the site and pull down the data
without any logon at all.

And for all cases, when you do link in this way, then you can build regular
VBA forms that edits that data. And, same goes for reports. Even more cool
is if you editing data and your connection breaks, then you can continue to
edit data (local). When the connection returns (or you return to some place
that has wiFi or back to the office and plug in to the internet), then the
data starts to flow and sync again. So, the connection build around a
disconnected model.

This means that breaks in the internet connection is not problem, but is in
fact part of the overall design. You can take your laptop out of the office,
and continue to run and use the application without an internet connection.


Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
Nospam_kallal (AT) msn (DOT) com

"The Frog" <mr.frog.to.you (AT) googlemail (DOT) com> wrote

Not only is he talking about SharePoint, but for Access 2010, we have Web
Services. Here is a video of an access 2010 application. At the half way
point, switch to running that application in a standard web browser. The new
access "WEB Services" run on SharePoint.

http://www.youtube.com/watch?v=AU4mH0jPntI


Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
Nospam_kallal (AT) msn (DOT) com

Albert D. Kallal wrote:

Well, a developer/owner probably has full permission. Others might have
(I'm guessing) read and write, and others simply read only. Are there
combinations of rights.
That's a wide open type of setup.
I figured if you have the rights as a developer you can. However, what
rights does/can one set up that would limit me from accessing your data
tables. Let's say I am a competitor and I want your client list. Even
tho we are competitor, I might be a client of yours or visa versa. If I
can access your web app, I can access the tables from my desktop
version? Where is the security if that's possible?
>

Where's the security?

If all else fails then implement an integrated security approach (my
preferred anyway). Your only real problem here is that your indexing
will go out the window, but each field can be encrypted independantly
if you want to go to the effort. You may also consider using something
different for a backend, say SQL Server, Postgres or MySQL, that has
integrated security (varying models depending on the product). I
imagine that Access FE with SQl Server BE is probably a great combo,
but I dont know if it works on Sharepoint? Albert.........?????

The Frog

The Frog wrote:

access to an account name/pw sounds dangerous. I'm going by mention of
what Albert said earlier.

"The Frog" <mr.frog.to.you (AT) googlemail (DOT) com> wrote


You develop 100% inside of ms-access. Your stored procedures, database
triggers are all done and built 100% inside of the desktop client. You then
whack the publish button and you done. All of those stored procedure etc.
then get sent up to the web site.

Those stored procedures and table logic will not work with mySql.

However, the most useful feature cut during the beta for a2010 was the BDC.
(just bing SharePoint BDC, I don't' have time to go into this). This would
have in fact allow you to use mySql, or just about any conceivable data
source that can produce data that looks like a table. This feature did not
make into a2010.

Some of us are hoping that a SP update will give us this BDC, as several of
us have suggested to the access team we can't wait until the next release
for this feature. It REALLY is missed.

Remember, you don't have to learn a new database, you don't have to learn
browser scripting. You don't have to learn the server side stuff. You don't
have to deal with HTML. You don't have to build connection strings to tie
your browser code to the database server. If you going to learn 5 different
systems to produce an web application, then you might as well not use
ms-access anyway. Access is a true RAD web development tool just like
access is now, and the fact that you don't have to learn 10 zillion systems
is why Access web is so cool.

I also means that I can build an applcaion and sell it to a company. With
other web tools, you now have to deal and hope on a wing and prayer that
they have ALL OF THE CORRECT database, web server, scirtiping support and 10
zillion other bits and pieces that are just RIGHT for your ONE application
to run. And, if they don't have the report writer you used, then will they
install it? Will your report writer you choose even run on their current web
site? There is just so many issues you have to deal with, and again, Access
Web + the correct sharePoint, and it just works...it just works...

Your stored procedures etc. can and do run 100% on the desktop via the ACE
data engine (even before you published the application). You don't need
SharePoint to develop your application (until you actually publish). Keep
in mind that the code you write in a form actually runs inside of the web
browser ON the users desktop (this why you see so few functions when writing
form code (no hour(), no day() functions for example).

The layout is in this diagram:
http://cid-b18a57cb5f6af0fa.office.l.../HOW%20WEB.png

By the way, the above is a illustration made for a access book coming out
this fall, and I even too busy to look up the name.....

have to run...

Albert K.