From: The Frog on 29 Jul 2010 03:14 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 30 Jul 2010 11:32 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 30 Jul 2010 16:20 "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 30 Jul 2010 17:17 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 31 Jul 2010 15:30 "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/
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 5 Prev: converting to access2003 from access97 Next: How to Populate Subform Automatically |