Prev: converting to access2003 from access97
Next: How to Populate Subform Automatically
From: Albert D. Kallal on 27 Jul 2010 14:14
"The Frog" <mr.frog.to.you(a)googlemail.com> wrote in message
news:04d86213-280e-4d7f-9986-bc47a1b214ef(a)f7g2000vbl.googlegroups.com...
> 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

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(a)msn.com


From: Salad on 27 Jul 2010 16:23
Albert D. Kallal wrote:

> "Salad" <salad(a)oilandvinegar.com> wrote in message
> news:5_OdnaMm0tTPi9PRnZ2dnUVZ_hcAAAAA(a)earthlink.com...
>
>> 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?
>>
>
> Yes, if you have permissions and a logon.

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

That's a wide open type of setup.
>
> 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.

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?
>
From: The Frog on 28 Jul 2010 02:40
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
From: Salad on 28 Jul 2010 11:16
The Frog wrote:

> Where's the security?
>
I don't know. The ability for anyone to link to the tables if they have
access to an account name/pw sounds dangerous. I'm going by mention of
what Albert said earlier.

> 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
From: Albert D. Kallal on 28 Jul 2010 11:29
"The Frog" <mr.frog.to.you(a)googlemail.com> wrote in message
news:66fdfb47-d9fc-49cf-866a-f4ef6b362c77(a)k19g2000yqc.googlegroups.com...

> 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

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.live.com/self.aspx/.Public/WebErrors/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.


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: converting to access2003 from access97
Next: How to Populate Subform Automatically