From: The Frog on
Hi Albert.

Thanks for the info. A2010 seems like a significant advancement over
previous versions. I did not realise that it was so simple to publish
an Access app as a web app. In the past, if I needed a more integrated
approach for an application to the web I would write it in Java for
the Apache Tomcat server, and if it was small scale just use H2 or
JavaDB (Derby). All of it contained in a single file (.war) that you
can push to the server and viola - job done. As with any app there is
always maintenance of course......

This A2010 with Sharepoint could dramatically reduce the dev time. I
will find out if it can work with MS SQL Server too for larger scale
projects. Albert, you have opened my eyes to a new set of
possibilities. But Salad is also quite right to be concerned about the
security of the app. I dont want people to be able to just grab my
tables 'raw', especially across the web. I would like to see a
minimalist approacch to granting permissions to objects etc.... they
only get access to it if they are specifically granted permission to
it. Time to do a little research.

Thanks Albert.

Cheers

The Frog
From: James A. Fortune on
On Jul 28, 11:29 am, "Albert D. Kallal"
<PleaseNOOOsPAMmkal...(a)msn.com> wrote:

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

That's an interesting perspective. Suppose I use Access 2010 as a RAD
web development tool. How difficult would it be to convert my RAD
website into something that doesn't use Access? It seems that the
"true RAD web development" is only true if everything stays as Access
web. I suppose using an old version of Access for RAD means about the
same thing. Setting up browser based forms on a LAN seems fine.
Outside of that (literally) it seems that Access is being stretched to
fit. The RAD facet might be a way of shoehorning Access web into that
niche. RAD, in general, is really great because it enhances early
communication with the customer about a new project in concrete
terms. Being able to adapt the "demo" quickly also gives the customer
confidence that you are adept, in spite of your warnings that you are
using a RAD environment :-). So it seems to me that Access web is
suitable for web demos, but is not really suited for practical
implementation. I hope the future proves that observation to be
incorrect. When I get more familiar with Access web I might be able
to make some better observations.

James A. Fortune
CDMAPoster(a)FortuneJames.com
From: Albert D. Kallal on
"James A. Fortune" <CDMAPoster(a)FortuneJames.com> wrote in message
news:fc909723-e1c5-4a61-93ea-d4312ea6e9d6(a)r27g2000yqb.googlegroups.com...
> On Jul 28, 11:29 am, "Albert D. Kallal"
> <PleaseNOOOsPAMmkal...(a)msn.com> wrote:
>
>> 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.
>
> That's an interesting perspective. Suppose I use Access 2010 as a RAD
> web development tool. How difficult would it be to convert my RAD
> website into something that doesn't use Access?

Well how hard would it be to convert an application to PHP when
you've written application using asp.net?

Or if you've written everything using python, how easy is it can be convert
to using ruby on rails?

I don't think the software industry really ever had any application
development process and methodology that's going to be interchangeable
between different sets of technology.

How are what you should realize here is that all of Access Web bits and
parts are based on the latest and more importantly standard web development
tools and technologies coming out of Redmond.

When you publish report in access web services, you actually wind up with a
SQL server report definition report (RDL). So you're using SQL server
reporting services for that.

And when you publish an access web form to the web, the resulting web form
is in fact a .net zammel (XAML) form. In fact you can fire up visual studio
and open up those forms and code and modify them with visual studio.

And, even more interesting is this stuff designed around Microsoft's cloud
computing initiative, which thus means massively scalable numbers of users
for those applications.

> So it seems to me that Access web is
> suitable for web demos, but is not really suited for practical
> implementation.

Why is it only suitable for web demos? This is all going to come down again
to what it is you're attempting to accomplish.

I would be the first to admit that one is not going to develop highly
complex and highly integrated applications like we do in the access client.

However at the end of the day, by their very nature most web based
applications tend to be quite scaled down and more simple to use then the
rich desktop counterparts anyway. Most web development in forms and
applications IC tend to be quite a bit simpler then the rich type of client
applications we develop, and that's why access is thus even unbelievably RAD
when it comes to web.

The fact the matter is is you have Desktop based system that allows you to
write code, have forms with code + events (that form by the way runs inside
of the browser on the users desktop, and SO DOES the form code you write -
it runs as JavaScript).

So, Access web allows one to tie the code + forms + reports in very much
what is a classic access type of approach for Access developers. The basic
features of continuous forms, and things such as sub forms accept a remains
in place. All of the basic parts needed for basic applications is included
in this one package, and the result is a really fantastic RAD tool.

Take a look of the following video of an web application I wrote. And, this
was the very first application I wrote in web services:

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

Albert K.

From: James A. Fortune on
On Jul 30, 4:20 pm, "Albert D. Kallal" <PleaseNOOOsPAMmkal...(a)msn.com>
wrote:
> "James A. Fortune" <CDMAPos...(a)FortuneJames.com> wrote in messagenews:fc909723-e1c5-4a61-93ea-d4312ea6e9d6(a)r27g2000yqb.googlegroups.com...
>
>
>
> > On Jul 28, 11:29 am, "Albert D. Kallal"
> > <PleaseNOOOsPAMmkal...(a)msn.com> wrote:
>
> >> 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.
>
> > That's an interesting perspective.  Suppose I use Access 2010 as a RAD
> > web development tool.  How difficult would it be to convert my RAD
> > website into something that doesn't use Access?
>
> Well how hard would it be to convert an application to PHP when
> you've written application using asp.net?
>
> Or if you've written everything using python, how easy is it can be convert
> to using ruby on rails?
>
> I don't think the software industry really ever had any application
> development process and methodology that's going to be interchangeable
> between different sets of technology.
>
> How are what you should realize here is that all of Access Web bits and
> parts are based on the latest and more importantly standard web development
> tools and technologies coming out of Redmond.
>
> When you publish report in access web services, you actually wind up with a
> SQL server report definition report (RDL). So you're using SQL server
> reporting services for that.
>
> And when you publish an access web form to the web, the resulting web form
> is in fact a .net zammel (XAML) form. In fact you can fire up visual studio
> and open up those forms and code and modify them with visual studio.
>
> And, even more interesting is this stuff designed around Microsoft's cloud
> computing initiative, which thus means massively scalable numbers of users
> for those applications.
>
> > So it seems to me that Access web is
> > suitable for web demos, but is not really suited for practical
> > implementation.
>
> Why is it only suitable for web demos? This is all going to come down again
> to what it is you're attempting to accomplish.
>
> I would be the first to admit that one is not going to develop highly
> complex and highly integrated applications like we do in the access client.
>
> However at the end of the day, by their very nature most web based
> applications tend to be quite scaled down and more simple to use then the
> rich desktop counterparts anyway. Most web development in forms and
> applications IC tend to be quite a bit simpler then the rich type of client
> applications we develop, and that's why access is thus even unbelievably RAD
> when it comes to web.
>
> The fact the matter is is you have Desktop based system that allows you to
> write code, have forms with code + events (that form by the way runs inside
> of the browser on the users desktop, and SO DOES the form code you write -
> it runs as JavaScript).
>
> So, Access web allows one to tie the code + forms + reports in very much
> what is a classic access type of approach for Access developers.  The basic
> features of continuous forms, and things such as sub forms accept a remains
> in place.  All of the basic parts needed for basic applications is included
> in this one package, and the result is a really fantastic RAD tool.
>
> Take a look of the following video of an web application I wrote. And, this
> was the very first application I wrote in web services:
>
> http://www.youtube.com/watch?v=AU4mH0jPntI
>
> Albert K.

If Access web creates truly standard web components, then Access 2010
will be useful indeed. I consider XAML and JavaScript truly
standard. RDL seems reminiscent of web servers requiring IIS, web
applications that require Internet Explorer, and HTML created by Word
that was beyond hideous. Right now, to me "Cloud Computing" is
equivalent to "Slow Computing." I'm about to use it, but I can't
argue against the value of the head office being able to compare all
the data from all their companies at one data center. So I don't
dispute your point that the cloud segment will be increasingly
important. I have found that the Access approach does lend itself to
web development, but in my case that was due to reliance on unbound
forms whenever the number of simultaneous users got large. Even with
SQL Server's capabilities, bound data outside a LAN doesn't seem to be
a good idea. Maybe SQL Server will prove equal to the challenge. I
hope so. Is SharePoint the glue that holds the Access web cloud data
together :-)? I'll find out soon. We've started using SharePoint
where I work and several copies of Access 2010 are likely to pop up
soon. They are already starting to use Workflows and will have a SQL
Server backend in the cloud for SAP in a few months. I'm exploring
options for customizing SAP right now, including .NET interfaces, so
all that C# study might be put to good use. Using Access to interface
with SAP is considered to be too much of a security risk. Beyond the
existing Access systems that are not part of SAP, I don't expect lots
of new requests for Access databases except for creating demos. I'd
still love to find a way to use .NET to have Access take advantage of
multiple client CPU cores, but with less Access databases running the
business it will be harder to justify that effort. I'm dubious, but
hopeful about the new tricks that Access has learned. BTW, I watched
all of your video. Your informative Access 2010 posts will be re-read
when I get ready to start trying out the web features. They will
likely save me some trouble. Thanks.

James A. Fortune
CDMAPoster(a)FortuneJames.com
From: David W. Fenton on
"Albert D. Kallal" <PleaseNOOOsPAMmkallal(a)msn.com> wrote in
news:LtG4o.33619$o27.22501(a)newsfe08.iad:

> However at the end of the day, by their very nature most web based
> applications tend to be quite scaled down and more simple to use
> then the rich desktop counterparts anyway. Most web development in
> forms and applications IC tend to be quite a bit simpler then the
> rich type of client applications we develop, and that's why access
> is thus even unbelievably RAD when it comes to web.

I'm not sure this is true. There's a whole world of people out there
who are developing full-scale apps for running in the browser that
20 years ago would have been compiled desktop apps. Sure, the nature
of HTML forms makes it impossible to do in one screen everything
that you can do in a single form in Access, but AJAX and Javascript
libraries like JQuery are closing the gap on that.

And, of course, the results of Access web apps running in the
browser show exactly how close it is possible to get to an Access
rich client interface!

The details of licensing and so forth are still for me the big issue
here, and I just can't see anybody selling Access as the development
platform for database-driven public-facing websites. That is not to
say that there is not a huge swath of applications that it doesn't
enable Access to compete for, but it's not going to be a generic
development method suitable everywhere, but one that is most
suitable for a particular type of application.

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/