Access 2010 with Sharepoint 2010
in [Help]
|
From: Salad on 11 Nov 2009 21:24 Albert, what would you recommend in preparation for Access 2010 and publishing an app to the web? I watched a demo of it, http://channel9.msdn.com/shows/Access/The-Access-Show-Episode-Two/ and http://channel9.msdn.com/shows/Access/Microsoft-Access-2010-Demo/. The people in the vid talked about Access Services and publishing to Sharepoint. They basically said "It's time to publish to Sharepoint, clicked a button or two, it went thru an update proces, and voila it was ready to work with on the web. Is it as simple as running a wizard, like the Database Splitter, and away one goes or is there some setup background we should be learning now? Do you see some difficulty in the process of getting the app from the desktop to the web...iow, is it a simple click the button or one needs to learn a certain technology in order to make it work? Would an admin person be able to publish an app to the web or will it take a braniac with years of experience to do so?
From: Albert D. Kallal on 11 Nov 2009 23:35 "David W. Fenton" <XXXusenet(a)dfenton.com.invalid> wrote in message news:Xns9CC0D6FE7B925f99a49ed1d0c49c5bbb2(a)74.209.136.82... > "Albert D. Kallal" <PleaseNOOOsPAMmkallal(a)msn.com> wrote in > > Uh, you obviously don't work with much older data. Two of my > clients' apps and one of my own research databases would be broken > by this. > I don't know what the "supposed" 100,000,000 SharePoint users are doing in this case, I have to assume the use 3 columns? > > Now I'm really confused. Are you saying that what them mean is that > a text field cannot contain a CrLf? That's crazy. > Yes. that is the case. Given that SharePoint is darn near all xml, so we talking the web and HTML data, then this is text data. It much like trying to import a CSV file into ms-access, there can't be any cr-lf's in the data stream. > When it says "Field is converted to a Multiple Lines of Text field > or Memo field" does that mean it's converted to one of two types of > field, or that "Multiple Lines of Text field" is a synonym for "Memo > field"? > > I'm having a hard time conceiving of a reason for making two > different kinds of text fields, one that can have CrLf in it and one > that can't -- the utility of that escapes me! Yes, I believe the above is the case. A memo could presumably store binary data, where the multi-line text field can't store binary data but does allow cr+lf's. I not a real web developer (yet!), and even passing xml data from a web service with markup tags (for fields) does hint that no cr+lf's are allowed in the text data stream. So, some type of data translation must/is needed here? I believe that is the case for most web services and explains this issue (somewhat). > > That's a pretty important lack, seems to me, especially given that > SQL Server has no problem with GUIDs (and it's SQL Server that > Sharepoint uses for its data store, right?). sql is used behind the scenes but SharePoint lists are still xml data cubes, and the whole system is designed to scale horizontal (many many users - cloud computing, these server farms have to scale out to millions of users). No question that the SharePoint xml "list" has been shoe-horned into now being a database, but that's because the success of SharePoint and how it being used has caught everyone off guard. The other issue is the VERY large goal of horizontal scalability (by horizontal , not huge amounts data, but huge amounts of users) > > So, no text PK/FK columns? Hmm. That's kind of problematic, seems to > me. I not tested the above otherwise, but that's how I see this (someone could jump in an correct on this, but I just not 100% sure on this one). >> So, you can declare a column called FullName which would be >> defined as: >> >> [FirstName] & " " & [LastName] >> >> Note that the ACTUAL value is stored in the above column. You >> don't really care that this column is an expression or is in fact >> calculated and stored into the actual table because this >> expression is enforced and managed at the table level by ACE. > > Is it editable or just readable? Read only. of course if you modify any field in the table that the expression is based on, then the column data has to be updated... > > Hmm. I have often created base queries for power users where I did > this kind of thing for them. I thinking putting it at the table > level is bad like table-level lookups, to be honest. > Yes in a pure data sense, it really breaks the relational data rule/model of storing redundant data. On the other hand, this is a much a scalability issue. You pull 100,000 rows, you saved that expression being evaluated 100,000 times. There is no question that some design decisions here are due to this all being designed for cloud computing, and that means processing is at a premium . So, in some cases, we going back to "storing" aggregate totals with triggers and thus can use those numbers without processing or having to pull more records from a related table. >Thanks for your answers, Albert. It really looks like they are putting a lot of really great ideas into this. You are welcome, and yes I think any investment into access is good. When our industry changed from text/green screen to GUI, some products did not make the jump. I view myself as a person who is rattling a little tin up and down and hoping Microsoft drops some coins into the little tin cup so we get new features for ms-access. I mean, VB6 is now 11 years old. There no new versions of FoxPro. We don't see dBase, clipper, Revelation, KnowledgeMan, Probase, R:BASE, Paradox, FMS-80, Reflex, they are all gone. Clipper never even made the jump to the GUI. Today, we seeing a huge move towards the cloud and the web. Access being married to office is good since it gets the $$, and access being married to office also means we often get things that are for office, and not really us access developers. Regardless, we are receiving features that helps the product even for non web stuff and these days I take any new bits with a smile, especially looking at the above long list of products that were once a common part of the desktop database market, but are now just fond memories along with Atari and Commodore computers. -- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKallal(a)msn.com
From: Albert D. Kallal on 12 Nov 2009 01:40 "Salad" <oil(a)vinegar.com> wrote in message news:ZP-dndDg2u5P7GbXnZ2dnUVZ_g2dnZ2d(a)earthlink.com... > Albert, what would you recommend in preparation for Access 2010 and > publishing an app to the web? > Good question! > Is it as simple as running a wizard, like the Database Splitter, and away > one goes or is there some setup background we should be learning now? ask yourself the following, have you ever upsized a couple of tables to SQL server? I mean if you're in an access application, it's only two or three mouse clicks to push a table up to SQL server. In fact, it's extremely easy to upsize a table to SQL server, and I often use the upsize option in place of the export option, both of which are very easy to use to export a table up into SQL server. On the other hand, if you've never used SQL server, then trying to upsize can be hard the 1st few times despite it being a few mouse clicks. When I look at the questions people had in the private beta group, a good number of them where kind of real basic beginner SharePoint related. For example when you click the button in access to upsize the application, and it asks you for Your SharePoint site name, well, did you create a Site on SharePoint to hold the application? So, you better have created a site in SharePoint BEFORE you publish. Now, anyone who used SharePoint will know what a site is and how to create one. this would be the same as me telling you that to type some text into word, you first have to create the word document. So, after I created a site, here is what a real url looks like: https://my-officehosted.spobeta.com/personal/$82n510-b54foi6vmlep/Test Access2/default.aspx The above is a site I just created. When access asks for the site to publish to, then you need to use the base url, which is: https://my-officehosted.spobeta.com/personal/$82n510-b54foi6vmlep/TestAccess2 Note how I removed the default.aspx part. So lot of people were pasting in the above 1st URL above and wondering why clicking on the publish command button was not working. Now the above was plain just obvious to me two years ago, and it was obvious to me when I was using SharePoint with access 2003. And it was I obvious to me when I was using SharePoint with access 2007. If you never published any tables to SharePoint, then the above little issue might cost you a whole afternoon to resolve because something that's completely obvious to me is not going to be obvious to a beginner has never done this before. so for me, the first time I have to do this, it was frustrating. However, all those little frustrating issues were spread over time for me. So, my first suggestion is to get some experience with SharePoint. However, you don't Need any SharePoint experience or knowledge or learning of any kind to build a web application with the access client. All you want to do is play with the absolute most basic features of SharePoint such as create a site (a workspace). Now put some word documents in it, open some word documents, throw up a couple of files. You just need the most basic experience here. It don't take long, in a couple of hours you'll be moving around and playing with SharePoint. It's fun and it's not hard, but if you have to learn all of the SharePoint stuff, at the very same time you're learning a whole bunch of new stuff in access, then instead of it being a pleasant experience, it can become quite a frustrating experience for you. And if you don't have access to SharePoint, then sign up for the free office live small business, that's what I did to learn SharePoint since I did not have SharePoint anywhere else. This whole thing of learning how to do this stuff is not hard at all, but it's like anything else you just have to sit down and spend a bit of time playing with this stuff. > Do you see some difficulty in the process of getting the app from the > desktop to the web...iow, is it a simple click the button or one needs to > learn a certain technology in order to make it work? To be absolutely honest, no you don't have to really learn anything about the server side technology at all. You build a web compatible application in access, and have a SharePoint site, then it really is a whack the button and then you watch your progress bar as a thing gets pushed up into the cloud. In fact, the hard parts are changing your mind as to how some things that you've taken for granted for so long actually become a bit of a mental challenge. Here is a perfect example: Have you ever sat down to think how your navigation for your website's going to work? I mean basic navigation from form to form in the access client is something that I never gave a second thought about in like 10 years. And, worse I was working with FoxPro and other products before access and the form navigation was done VERY much the same way. So in effect I really never had to sit down and think about the layout and how navigation for this web application going to work. So, for the web you now have to change how this navigation and how you go from when form to the next is going to work. It would not make sense for you to click on one form, and then for each form a new copy of the browser is launched. How could you possibly control what the user does next? This is not really an access problem is as much as it's sitting down and starting to scribble on paper how you are going to navigate through your application now. It only took me the better part of an afternoon falling half asleep on a couch thinking how I going to setup the navigation. I had never made out the web navigation, so the 1st time was extra mental effort. Now that I made one Application , then the next ones will be easy.... So, some very simple things like navigation from form to form has to be given some thought. You'll also have to approach your software designs differently. What you've done for years that made a lot of sense to do it in a rich client, will not translate over to a browser based system. So this change in mentality is hard sometimes because we're used to designing and building and doing things without thinking about what we're doing, because we're so good at it and we been doing such and such way for so many years. For example you're not going to write code in a form that traverses a record set, and it's not even allowed. For some people this is difficult since that what you done for many years. If you don't have patience to learn new ways to do things, then you're in for rough ride. For example we for years in this newsgroup had FoxPro people coming in and asking how come there's no record numbers in access? The answer was well we don't use them in access! However, people coming over from clipper or FoxPro/dBase III were using record numbers for all of their programming career. Now they are being told they can not use them anymore! If you insist on using record numbers in your software designs that worked in FoxPro, that design would not work in access. if you can make mental changes like that, then the web thing in access will be frustrating. The web stuff is exactly the same, you must be willing to very much changed how you've done some things. In other words, the wizard is only a couple most clicks to whack a and publish the application. It is everything else you have to "change" in how you approach things. At the end of the day the question becomes the following: Are you willing to spend a few afternoons learning this new system as opposed to spending a very long time to learn another web development system? Those other systems means you need some type of SQL server, some new database trigger and programming language, learning a web server and likely some type of web scripting language? Developing applications that run a browser takes a tremendous amount of technology, and you tend to have to learn several different server systems to make it all happen. This explains why so often that web applications are developed by a team of two or three people. One person knows the browser scripting, one knows the web stuff and another builds the application or logic part. Access gives you a huge shortcut in this regards, and will allow a single person to develop a system with a database, tables, cool forms and reports. And, you can do it without that team of developers. All of these things are easy, but you really have to be willing to change your mind as to how you do some things. If you look closely at my video, you see that most all the forms I've turned off the record navigation buttons for example. For me, all this learning stuff is a blast, and it very much what I crave and do. I love to learn these things..and that helps me a lot here... > Would an admin person be able to publish an app to the web or will it take > a braniac with years of experience to do so? Like I said, the publishing part is really trivial...it the mind change that some people can't do well. When you see the long list of functions that disappear when inside of a form's code, you simply can't believe how the heck you going to write an application. For example, in a form's code you don't have the date functions like DateSerial(), but I write a booking application in which I deal with dates and times in the applicaion, and I had little trouble doing this (once I got over the shock of not having those features, then realizing there was a completely different approach here that really worked well!). -- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKallal(a)msn.com
From: Salad on 12 Nov 2009 03:21 Albert D. Kallal wrote: > "Salad" <oil(a)vinegar.com> wrote in message > news:ZP-dndDg2u5P7GbXnZ2dnUVZ_g2dnZ2d(a)earthlink.com... > >>Albert, what would you recommend in preparation for Access 2010 and >>publishing an app to the web? >> > > > Good question! > > >>Is it as simple as running a wizard, like the Database Splitter, and away >>one goes or is there some setup background we should be learning now? > > > ask yourself the following, have you ever upsized a couple of tables to SQL > server? > > I mean if you're in an access application, it's only two or three mouse > clicks to push a table up to SQL server. In fact, it's extremely easy to > upsize a table to SQL server, and I often use the upsize option in place of > the export option, both of which are very easy to use to export a table up > into SQL server. > > On the other hand, if you've never used SQL server, then trying to upsize > can be hard the 1st few times despite it being a few mouse clicks. > > When I look at the questions people had in the private beta group, a good > number of them where kind of real basic beginner SharePoint related. For > example when you click the button in access to upsize the application, and > it asks you for Your SharePoint site name, well, did you create a Site on > SharePoint to hold the application? So, you better have created a site in > SharePoint BEFORE you publish. Now, anyone who used SharePoint will know > what a site is and how to create one. this would be the same as me telling > you that to type some text into word, you first have to create the word > document. > > So, after I created a site, here is what a real url looks like: > > https://my-officehosted.spobeta.com/personal/$82n510-b54foi6vmlep/Test > Access2/default.aspx > > The above is a site I just created. When access asks for the site to publish > to, then you need to use the base url, which is: > > https://my-officehosted.spobeta.com/personal/$82n510-b54foi6vmlep/TestAccess2 > > Note how I removed the default.aspx part. So lot of people were pasting in > the above 1st URL above and wondering why clicking on the publish command > button was not working. > In my reader, the first URL broke and wordwrapped at the word Test so I copy pasted Access2/default.aspx to it. Then I noticed your second URL was the same w/o the "default.aspx". Both sends me to a page to logon with name and pw. I guess I need a valid logon first. Is this what you were demo'ing? Is this at this point you'd recommend signing up for officelive? > Now the above was plain just obvious to me two years ago, and it was obvious > to me when I was using SharePoint with access 2003. And it was I obvious to > me when I was using SharePoint with access 2007. If you never published any > tables to SharePoint, then the above little issue might cost you a whole > afternoon to resolve because something that's completely obvious to me is > not going to be obvious to a beginner has never done this before. so for me, > the first time I have to do this, it was frustrating. > > However, all those little frustrating issues were spread over time for me. > > So, my first suggestion is to get some experience with SharePoint. However, > you don't Need any SharePoint experience or knowledge or learning of any > kind to build a web application with the access client. That will be of benefit for MS in the adoption of the new technology. And for us. If the learning curve was so steep, it'd be hard to get people to adapt. We want things to get easier, not harder. > All you want to do is play with the absolute most basic features of > SharePoint such as create a site (a workspace). Now put some word documents > in it, open some word documents, throw up a couple of files. You just need > the most basic experience here. It don't take long, in a couple of hours > you'll be moving around and playing with SharePoint. It's fun and it's not > hard, but if you have to learn all of the SharePoint stuff, at the very same > time you're learning a whole bunch of new stuff in access, then instead of > it being a pleasant experience, it can become quite a frustrating experience > for you. > > And if you don't have access to SharePoint, then sign up for the free office > live small business, that's what I did to learn SharePoint since I did not > have SharePoint anywhere else. > > This whole thing of learning how to do this stuff is not hard at all, but > it's like anything else you just have to sit down and spend a bit of time > playing with this stuff. Great advice. >>Do you see some difficulty in the process of getting the app from the >>desktop to the web...iow, is it a simple click the button or one needs to >>learn a certain technology in order to make it work? > > > To be absolutely honest, no you don't have to really learn anything about > the server side technology at all. You build a web compatible application > in access, and have a SharePoint site, then it really is a whack the button > and then you watch your progress bar as a thing gets pushed up into the > cloud. > > In fact, the hard parts are changing your mind as to how some things that > you've taken for granted for so long actually become a bit of a mental > challenge. > > Here is a perfect example: > > Have you ever sat down to think how your navigation for your website's going > to work? I mean basic navigation from form to form in the access client is > something that I never gave a second thought about in like 10 years. And, > worse I was working with FoxPro and other products before access and the > form navigation was done VERY much the same way. So in effect I really never > had to sit down and think about the layout and how navigation for this web > application going to work. > > So, for the web you now have to change how this navigation and how you go > from when form to the next is going to work. > > It would not make sense for you to click on one form, and then for each form > a new copy of the browser is launched. How could you possibly control what > the user does next? This is not really an access problem is as much as it's > sitting down and starting to scribble on paper how you are going to navigate > through your application now. It only took me the better part of an > afternoon falling half asleep on a couch thinking how I going to setup the > navigation. I had never made out the web navigation, so the 1st time was > extra mental effort. Now that I made one Application , then the next ones > will > be easy.... > > So, some very simple things like navigation from form to form has to be > given some thought. > > You'll also have to approach your software designs differently. What you've > done for years that made a lot of sense to do it in a rich client, will not > translate over to a browser based system. So this change in mentality is > hard sometimes because we're used to designing and building and doing things > without thinking about what we're doing, because we're so good at it and we > been doing such and such way for so many years. > > For example you're not going to write code in a form that traverses a record > set, and it's not even allowed. For some people this is difficult since that > what you done for many years. > > If you don't have patience to learn new ways to do things, then you're in > for rough ride. For example we for years in this newsgroup had FoxPro people > coming in and asking how come there's no record numbers in access? The > answer was well we don't use them in access! However, people coming over > from clipper or FoxPro/dBase III were using record numbers for all of their > programming career. Now they are being told they can not use them anymore! > If > you insist on using record numbers in your software designs that worked in > FoxPro, that design would not work in access. if you can make mental > changes like that, then the web thing in access will be frustrating. > > The web stuff is exactly the same, you must be willing to very much changed > how you've done some things. > > In other words, the wizard is only a couple most clicks to whack a and > publish the application. > > It is everything else you have to "change" in how you approach things. > > At the end of the day the question becomes the following: > > Are you willing to spend a few afternoons learning this new system > as opposed to spending a very long time to learn another web development > system? Those other systems means you need some type of SQL server, some new > database trigger and programming language, learning a web server and likely > some type of web scripting language? > > Developing applications that run a browser takes a tremendous amount of > technology, and you tend to have to learn several different server systems > to make it all happen. This explains why so often that web applications are > developed by a team of two or three people. One person knows the browser > scripting, one knows the web stuff and another builds the application or > logic part. > > Access gives you a huge shortcut in this regards, and will allow a single > person to develop a system with a database, tables, cool forms and reports. > And, you can do it without that team of developers. > > All of these things are easy, but you really have to be willing to change > your mind as to how you do some things. > > If you look closely at my video, you see that most all the forms I've turned > off the record navigation buttons for example. > > For me, all this learning stuff is a blast, and it very much what I crave > and do. > > I love to learn these things..and that helps me a lot here... > It certainly sounds like it will be fun and a new challenge. One couple of other question, if you have the time. Are all tables in Sharepoint (for web/collaboration use) or can you have some tables in Sharepoint and others local (like a personal table in the front end) and others in a backend at the corporate site? Do you have forms like Customer and CustomerWeb? If customer, it has everything to work on the desktop, CustomerWeb for viewing on the web, doesn't use DateSerial or other "missing" pieces? Or maybe two apps; one for desktop use, the other for web? Or do you recommend a one-size fits all approach? >>Would an admin person be able to publish an app to the web or will it take >>a braniac with years of experience to do so? > > > Like I said, the publishing part is really trivial...it the mind change that > some people can't do well. > > When you see the long list of functions that disappear when inside of a > form's code, you simply can't believe how the heck you going to write an > application. For example, in a form's code you don't have the date functions > like DateSerial(), but I write a booking application in which I deal with > dates and times in the applicaion, and I had little trouble doing this (once > I got over the shock of not having those features, then realizing there was > a completely different approach here that really worked well!). > > Your response has me stoked! Thank you for the time you spent answering my questions.
From: Roger on 12 Nov 2009 06:41
On Nov 11, 11:40 pm, "Albert D. Kallal" <PleaseNOOOsPAMmkal...(a)msn.com> wrote: > "Salad" <o...(a)vinegar.com> wrote in message > > news:ZP-dndDg2u5P7GbXnZ2dnUVZ_g2dnZ2d(a)earthlink.com... > > > Albert, what would you recommend in preparation for Access 2010 and > > publishing an app to the web? > > Good question! > > > Is it as simple as running a wizard, like the Database Splitter, and away > > one goes or is there some setup background we should be learning now? > > ask yourself the following, have you ever upsized a couple of tables to SQL > server? > > I mean if you're in an access application, it's only two or three mouse > clicks to push a table up to SQL server. In fact, it's extremely easy to > upsize a table to SQL server, and I often use the upsize option in place of > the export option, both of which are very easy to use to export a table up > into SQL server. > > On the other hand, if you've never used SQL server, then trying to upsize > can be hard the 1st few times despite it being a few mouse clicks. > > When I look at the questions people had in the private beta group, a good > number of them where kind of real basic beginner SharePoint related. For > example when you click the button in access to upsize the application, and > it asks you for Your SharePoint site name, well, did you create a Site on > SharePoint to hold the application? So, you better have created a site in > SharePoint BEFORE you publish. Now, anyone who used SharePoint will know > what a site is and how to create one. this would be the same as me telling > you that to type some text into word, you first have to create the word > document. > > So, after I created a site, here is what a real url looks like: > > https://my-officehosted.spobeta.com/personal/$82n510-b54foi6vmlep/Test > Access2/default.aspx > > The above is a site I just created. When access asks for the site to publish > to, then you need to use the base url, which is: > > https://my-officehosted.spobeta.com/personal/$82n510-b54foi6vmlep/Tes... > > Note how I removed the default.aspx part. So lot of people were pasting in > the above 1st URL above and wondering why clicking on the publish command > button was not working. > > Now the above was plain just obvious to me two years ago, and it was obvious > to me when I was using SharePoint with access 2003. And it was I obvious to > me when I was using SharePoint with access 2007. If you never published any > tables to SharePoint, then the above little issue might cost you a whole > afternoon to resolve because something that's completely obvious to me is > not going to be obvious to a beginner has never done this before. so for me, > the first time I have to do this, it was frustrating. > > However, all those little frustrating issues were spread over time for me.. > > So, my first suggestion is to get some experience with SharePoint. However, > you don't Need any SharePoint experience or knowledge or learning of any > kind to build a web application with the access client. > > All you want to do is play with the absolute most basic features of > SharePoint such as create a site (a workspace). Now put some word documents > in it, open some word documents, throw up a couple of files. You just need > the most basic experience here. It don't take long, in a couple of hours > you'll be moving around and playing with SharePoint. It's fun and it's not > hard, but if you have to learn all of the SharePoint stuff, at the very same > time you're learning a whole bunch of new stuff in access, then instead of > it being a pleasant experience, it can become quite a frustrating experience > for you. > > And if you don't have access to SharePoint, then sign up for the free office > live small business, that's what I did to learn SharePoint since I did not > have SharePoint anywhere else. > > This whole thing of learning how to do this stuff is not hard at all, but > it's like anything else you just have to sit down and spend a bit of time > playing with this stuff. > > > Do you see some difficulty in the process of getting the app from the > > desktop to the web...iow, is it a simple click the button or one needs to > > learn a certain technology in order to make it work? > > To be absolutely honest, no you don't have to really learn anything about > the server side technology at all. You build a web compatible application > in access, and have a SharePoint site, then it really is a whack the button > and then you watch your progress bar as a thing gets pushed up into the > cloud. > > In fact, the hard parts are changing your mind as to how some things that > you've taken for granted for so long actually become a bit of a mental > challenge. > > Here is a perfect example: > > Have you ever sat down to think how your navigation for your website's going > to work? I mean basic navigation from form to form in the access client is > something that I never gave a second thought about in like 10 years. And, > worse I was working with FoxPro and other products before access and the > form navigation was done VERY much the same way. So in effect I really never > had to sit down and think about the layout and how navigation for this web > application going to work. > > So, for the web you now have to change how this navigation and how you go > from when form to the next is going to work. > > It would not make sense for you to click on one form, and then for each form > a new copy of the browser is launched. How could you possibly control what > the user does next? This is not really an access problem is as much as it's > sitting down and starting to scribble on paper how you are going to navigate > through your application now. It only took me the better part of an > afternoon falling half asleep on a couch thinking how I going to setup the > navigation. I had never made out the web navigation, so the 1st time was > extra mental effort. Now that I made one Application , then the next ones > will > be easy.... > > So, some very simple things like navigation from form to form has to be > given some thought. > > You'll also have to approach your software designs differently. What you've > done for years that made a lot of sense to do it in a rich client, will not > translate over to a browser based system. So this change in mentality is > hard sometimes because we're used to designing and building and doing things > without thinking about what we're doing, because we're so good at it and we > been doing such and such way for so many years. > > For example you're not going to write code in a form that traverses a record > set, and it's not even allowed. For some people this is difficult since that > what you done for many years. > > If you don't have patience to learn new ways to do things, then you're in > for rough ride. For example we for years in this newsgroup had FoxPro people > coming in and asking how come there's no record numbers in access? The > answer was well we don't use them in access! However, people coming over > from clipper or FoxPro/dBase III were using record numbers for all of their > programming career. Now they are being told they can not use them anymore! > If > you insist on using record numbers in your software designs that worked in > FoxPro, that design would not work in access. if you can make mental > changes like that, then the web thing in access will be frustrating. > > The web stuff is exactly the same, you must be willing to very much changed > how you've done some things. > > In other words, the wizard is only a couple most clicks to whack a and > publish the application. > > It is everything else you have to "change" in how you approach things. > > At the end of the day the question becomes the following: > > Are you willing to spend a few afternoons learning this new system > as opposed to spending a very long time to learn another web development > system? Those other systems means you need some type of SQL server, some new > database trigger and programming language, learning a web server and likely > some type of web scripting language? > > Developing applications that run a browser takes a tremendous amount of > technology, and you tend to have to learn several different server systems > to make it all happen. This explains why so often that web applications are > developed by a team of two or three people. One person knows the browser > scripting, one knows the web stuff and another builds the application or > logic part. > > Access gives you a huge shortcut in this regards, and will allow a single > person to develop a system with a database, tables, cool forms and reports. > And, you can do it without that team of developers. > > All of these things are easy, but you really have to be willing to change > your mind as to how you do some things. > > If you look closely at my video, you see that most all the forms I've turned > off the record navigation buttons for example. > > For me, all this learning stuff is a blast, and it very much what I crave > and do. > > I love to learn these things..and that helps me a lot here... > > > Would an admin person be able to publish an app to the web or will it take > > a braniac with years of experience to do so? > > Like I said, the publishing part is really trivial...it the mind change that > some people can't do well. > > When you see the long list of functions that disappear when inside of a > form's code, you simply can't believe how the heck you going to write an > application. For example, in a form's code you don't have the date functions > like DateSerial(), but I write a booking application in which I deal with > dates and times in the applicaion, and I had little trouble doing this (once > I got over the shock of not having those features, then realizing there was > a completely different approach here that really worked well!). > > -- > Albert D. Kallal (Access MVP) > Edmonton, Alberta Canada > pleaseNOOSpamKal...(a)msn.com |