Access 2010 with Sharepoint 2010
in [Help]
|
From: Roger on 12 Nov 2009 06:42 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 So if you don't have date() functions, how would you deal with dateSerial()
From: Albert D. Kallal on 12 Nov 2009 13:15 "Salad" <oil(a)vinegar.com> wrote in message news:EcGdnajpsOsJWGbXnZ2dnUVZ_oOdnZ2d(a)earthlink.com... > > In my reader, the first URL broke and wordwrapped at the word Test so I > copy pasted Access2/default.aspx to it. Well I'm not asking you to attempt to log into my web site development space! > thenn 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. Yes, I was just giving an example here are as to what a URL from SharePoint that access is expecting when you publish. as I said, this is not a whole lot different than explain to somebody is that you can type a few characters into word, you have to create a blank document first or least be in a blank document before you can start typing! This is just the same kind of thing... >Is this what you were demo'ing? Yes, that is the site were that demo resides right now. It is private at this time. > Is this at this point you'd recommend signing up for officelive? Sure, office live was just a suggestion. As I said you don't need SharePoint to start playing with the stuff in the access client side of things. This is just like anything else and if you have a big term paper due tomorrow, then I don't think tomorrow is the time that you should start learning to use word and learn how to use word for the very first time! You can spend a bit of time playing around with word, then when you're in a crunch for your term paper the night before you won't be so frustrated with having to learn word to get your paper done. In fact, I'm not really sure if this advice has really anything to do with software at all, but just common sense and how one approaches learning and doing things in one's life. > > 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? In your application, you can link to SharePoint tables, or you can link to mdb/accDB data files that reside on your local desktop. > > Do you have forms like Customer and CustomerWeb? You can certainly mix and match pieces of the application. So if you build a payroll system, all the complex tax calculations and everything used on the desktop by the controller/accountant guy would make sense in the rich client. However, the part where the employees login to see what their holiday pay is, and choose when they're going to take time off work etc, well that part would make sense for the web portion (the web portal part). So not only is it encouraged to have hybrid type applications, my bets are that's what most applications will look like. However as mentioned, if you look at my demo close, when I launch been the client, those are the same web forms that I use for the web and I also use them in the client. In other words a web form in the access client looks and behaves really like any other access form you would build. So for continuous form, or a form that navigate select you added a few records, you likely would not have different forms for client and web. > 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? Well the best approach is to make a form that works for both client and the web. However for some things like payroll processing etc then you need VBA. Obviously only the controller/accountant person in your organization will need the advance VBA part of the application. For employees to enter their time sheets and hours, check their holiday pay, or even perhaps schedule when they want their holidays, then the web portal part of the application makes perfect sense. In fact it's better, since the average employee the organization should not have to learn and use and figure out a complex payroll system you write in access. So, users will not need to have a copy of your application, and you really don't want them to have the payroll application when they are only entering hours and timesheets into that payroll system anyway... -- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKallal(a)msn.com
From: Salad on 12 Nov 2009 15:54 Albert D. Kallal wrote: > "Salad" <oil(a)vinegar.com> wrote in message > news:EcGdnajpsOsJWGbXnZ2dnUVZ_oOdnZ2d(a)earthlink.com... > > >>In my reader, the first URL broke and wordwrapped at the word Test so I >>copy pasted Access2/default.aspx to it. > > > Well I'm not asking you to attempt to log into my web site development > space! > > >>thenn 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. > > > Yes, I was just giving an example here are as to what a URL from SharePoint > that access is expecting when you publish. as I said, this is not a whole > lot different than explain to somebody is that you can type a few characters > into word, you have to create a blank document first or least be in a blank > document before you can start typing! This is just the same kind of thing... > > >>Is this what you were demo'ing? > > > Yes, that is the site were that demo resides right now. It is private at > this time. > > >> Is this at this point you'd recommend signing up for officelive? > > > Sure, office live was just a suggestion. As I said you don't need SharePoint > to start playing with the stuff in the access client side of things. This is > just like anything else and if you have a big term paper due tomorrow, then > I don't think tomorrow is the time that you should start learning to use > word and learn how to use word for the very first time! You can spend a bit > of time playing around with word, then when you're in a crunch for your term > paper the night before you won't be so frustrated with having to learn word > to get your paper done. In fact, I'm not really sure if this advice has > really anything to do with software at all, but just common sense and how > one approaches learning and doing things in one's life. > > >>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? > > > In your application, you can link to SharePoint tables, or you can link to > mdb/accDB data files that reside on your local desktop. > > >>Do you have forms like Customer and CustomerWeb? > > > You can certainly mix and match pieces of the application. So if you build a > payroll system, all the complex tax calculations and everything used on the > desktop by the controller/accountant guy would make sense in the rich > client. However, the part where the employees login to see what their > holiday pay is, and choose when they're going to take time off work etc, > well that part would make sense for the web portion (the web portal part). > So not only is it encouraged to have hybrid type applications, my bets are > that's what most applications will look like. > > However as mentioned, if you look at my demo close, when I launch been the > client, those are the same web forms that I use for the web and I also use > them in the client. In other words a web form in the access client looks and > behaves really like any other access form you would build. So for continuous > form, or a form that navigate select you added a few records, you likely > would not have different forms for client and web. > > >>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? > > > Well the best approach is to make a form that works for both client and the > web. However for some things like payroll processing etc then you need VBA. > Obviously only the controller/accountant person in your organization will > need the advance VBA part of the application. For employees to enter their > time sheets and hours, check their holiday pay, or even perhaps schedule > when they want their holidays, then the web portal part of the application > makes perfect sense. In fact it's better, since the average employee the > organization should not have to learn and use and figure out a complex > payroll system you write in access. So, users will not need to have a copy > of your application, and you really don't want them to have the payroll > application when they are only entering hours and timesheets into that > payroll system anyway... > > Thanks for answering my questions. I got myself an OfficeLive account. Seems most of the setup work is done, very straightforward. Now I need to wait for Access 2010. Your prediction; early, mid, or late 2010?
From: Bob Alston on 12 Nov 2009 16:01 Salad wrote: Now I need > to wait for Access 2010. Your prediction; early, mid, or late 2010? I have read that a public beta is going to be announced soon, perhaps next week. bob
From: David W. Fenton on 12 Nov 2009 16:05
"Albert D. Kallal" <PleaseNOOOsPAMmkallal(a)msn.com> wrote in news:5gMKm.23451$Wf2.8231(a)newsfe23.iad: > "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 > >> 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. Of course there can -- the file just has to be properly delimited. I upload data with linefeeds in it to a client website all the time. I don't use XML, just an HTML POST operation, but it works just fine. I do have some problems with the interaction between HTML form text fields that somehow strip out <p> typed into them and replace them with line feeds, but that's a different problem entirely (in the opposite direction, in fact). So, I just don't see what the issue is. >> 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). I don't know anything about web services, but I've had no trouble URL encoding data for parameters in POST operations that include linefeeds and they go through just fine and get properly stored in my client's MySQL database (using PHP, but the PHP doesn't touch the data arguments for the POST parameters, it just formats the SQL string and executes). >> 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). I just Googled "xml data cube," a term that is 100% meaningless to me, and got no useful results. Please explain. > 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) This is yet another case (as with A2000) where MS is driving the development of Access based on goals that are as far from the needs of my clients as is possible. My clients don't need 100s of users. They don't need dozens of users. They mostly don't even need more than 2 or 3. But Microsoft doesn't care about my clients. They haven't for a very, very long time (despite the false dawn of Office 97 with VBA as platform for developing complex meta-apps for small businesses). >>> 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... I don't quite understand why this is important to implement. It looks like something as useless to an actual Access developer as multi-value fields. >> 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. But in a browser-based app it is only run in the presentation layer. For that matter, it is likely only calculated in Access at the presentation layer, except when you want to sort on it. Do these derived fields get indexed automatically, or are you allowed to index them? That *could* be useful if you often need to sort large amounts of data on calculated fields. > 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. But why does this have to be put into Access? Why can't Sharepoint do whatever it needs to scale, and leave Access alone? It's not like you're going to have more than 255 users of an ACCDB, right? [] > Today, we seeing a huge move towards the cloud and the web. I don't see this for the kind of apps I have been hired to create/revise over the last 13 years. My clients need the web, but they don't need their database apps to be connected to it. Both of my clients who drive public-facing websites with data that ultimately comes from the Access apps see it as an advantage that the data on the website is a slave of their Access app, and a subset of it. They don't *want* 100% of the data on their websites, and they don't want the security headaches and latency problems that come with moving local data up to 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. I think the web thing is a big deal. As much as I badmouth ADPs, a lot of people got really excited about them, and I think it drove a commitment from enterprise-level organizations that likely wouldn't have been as strong without it. It didn't work out, unfortunately, mostly because the reason for ADPs existing in the first place were misguided (Jet wasn't the problem; the ignorance of developers in understanding how to use Jet to work with ODBC data was the problem; redesigning an Access client to bypass Jet was cutting of your nose to spite your face, and doing it for the purpose of winning over people who just didn't understand how they were supposed to be use Access in the first place; but I digress...). I fear the same tail-wags-the-dog situation with Sharepoint, particularly given that the goals with Sharepoing are so antithetical to the needs of the small business (at least, the small businesses I have any interaction with). On the other hand, if the web adaptation allows more people to do useful things with Access, as long as they don't make it mandatory, it's going to expand the number of people using Access, which means it will remain a viable platform for a long time. As long as they don't pull a Paradox4Win on us (i.e., by entirely replacing the old development language with a new and much better one that was completely incompatible with the old, familiar language), I think we'll be OK. That's not the kind of thing Microsoft does, so I'm not too worried about there being a gutting of the major features of Access that we've become familiar with. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ |