Access 2010 with Sharepoint 2010
in [Help]
|
From: David W. Fenton on 8 Nov 2009 20:21 "Albert D. Kallal" <PleaseNOOOsPAMmkallal(a)msn.com> wrote in news:QBqJm.2507$rE5.2452(a)newsfe08.iad: > "David W. Fenton" <XXXusenet(a)dfenton.com.invalid> wrote in message > news:Xns9CBCC354C8849f99a49ed1d0c49c5bbb2(a)74.209.136.91... > >> >> How else can you figure out what's not going to work as well in >> the browser as in Access itself? Surely you're not claiming that >> 100% of an Access app is going to convert to the browser-based >> Sharepoint version and have exactly the same performance and ease >> of use? > > Well, actually, yes I kind of am making this claim. But in other posts you're saying something completely different, that only the forms created in Access as web forms are converted. > You certainly have to deal with increased latency, but on the > other hand since there's no data transfer down the wire, you > actually get some bonuses perofrmance also. But the widgets in web browsers simply suck, even when extended with AJAX. And continuous forms? Hello? > You certanly have to choose a "web database" option for this to > happen. When you do this access will restrict your feature set to > web only features -- in fact this option even automatically > restricts the macro feature set available for you. So, for web > forms you see a reduced set of form events in the Property sheet > for example. You also see a reduced set of events that appear for > controls on your forms. Is there any documentation anywhere describing these limitations? It would be very useful to know that. > At that point what you build on the desktop will go up to > sharepoint exactly as it is with all of its event code, on-dirty, > on-curret code etc. All of it should/will work the same in the > browser. You have to use macro code (they added embeeded macros in > 2007 but it really was for 2010!). I've said elsewhere that I'm wary of embedded macros because of the maintenance and auditability problems that come with them. Is there anything that addresses this? Can you write macros that are shared in multiple forms (i.e., not embedded) and those will be uploaded and used appropriately? Or are you limited to the embedded macros? And can embedded macros call things outside themselves? And, of so, to what degree? > No question there going to be a somewhat different of an > experiance of running in an browsser, but it those differences > minor and something you'll learn after publishing a few forms. > From that point on there not really much differnce . The fidelity > and how those forms render in a browser is absolutely > stunning....nothing short of increiable.. But it's not your Access forms, but your Access *web* forms that you're talking about. That's a crucial difference. An existing app can't just be converted without recreating its Access forms as web forms, correct? Or is there conversion available, such as a SAVE AS that strips out what isn't supported (and tells you what's omitted)? > So, yes, I am saying there is almost no reason to have the server > bits running during the development process. But have you addressed the question about the differences between the free version available on Office Live, the pay version hosted there, and the full Sharepoint server hosted locally? Are they identically in functionality for a single user? [] > Access will tell you if that database is compatible with the web. > If the web app passes the compatibility checker (and it should if > you started out developing a web only application), then it will > publish up to SharePoint). How good is its rundown of the incompatiblities? Is it easy to work from to get it into shape to be compatible for upload? > As I said, compared to any other web development systems, you'll > not be playing with connection strings, you'll not be playing with > HTML, you'll not be playing with some database server. You'll > simply be working with your little local access system like you've > always done. But not with native Access forms. Not with standard VBA. This means it may be *similar* to Access (and thus very easy for us to learn), but it isn't Access as we've known it and used it in the past. [] >> Testing on all the target deployment platforms is not just a >> matter of getting a thrill but a necessary part of any serious >> developer's basic responsibilities. > > That's true. When I build an access application now, I build and > develop the system on my machine. I as a general rule can assume > that when I deploy to the client system, it will work the same. But you wouldn't build in A2003 for distribution on A2007 without testing it in A2007 would you? Likewise, you wouldn't build for Sharepoint without testing it on the deployed version of Sharepoint. > So for web stuff, the paradigm is pretty darn similar for me. You > really can develop most if not all of your application on the > desktop before you ever attempt to publish it... I am skeptical about all of this. I think you're elliding a lot of the differences between standard Access in order to laud the new platform's ability to produce Web apps easily. That's value, true, but it's not exactly what I or my clients are looking for. I don't have any clients who need their app deployed to run in a web browser -- not a single one. Why would it then suddenly be valuable to them to be able to do so? Sure, I can think of some marginal utility coming from that capability, but if it requires major redevelopment (as it surely will to convert an existing Access form to an Access web form), the cost becomes high, and if there isn't a real need for web deployment, the cost far exceeds the benefit. Now, for new development, sure, it could be a different balance. But I haven't had contract for a build-from-scratch brand-new Access app of any degree of complexity in over 5 years -- all my work now is maintaining the apps of my existing client base, and taking on new clients with existing apps that need to be revised, updated and expanding. Nobody is asking for web deployment. Some have needed remote access, but WTS takes care of that without needing to alter the existing app in any way. So, exciting as all these new features may be, I don't think they are directed at the needs of the users of existing Access apps, except in those cases where the Access app needs to be ported to the web. I know that question comes up a lot, and this will be a new and attractive alternative to the not-so-attractive set of alternatives that have been available before. But that's not *my* client base, so I'm having some difficulty seeing how this is going to benefit the people who pay my bills. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/
From: Bob Alston on 8 Nov 2009 21:04 <David Fentom wrote: <But I haven't had contract for a build-from-scratch brand-new Access <app of any degree of complexity in over 5 years -- all my work now <is maintaining the apps of my existing client base, and taking on <new clients with existing apps that need to be revised, updated and <expanding. Perhaps then your Access business is dying. <Nobody is asking for web deployment. I hear of lots of people asking for web development. something that to date I have done very little of. so David, perhaps they know you are Access focused and look elsewhere for web development. Bob
From: Albert D. Kallal on 9 Nov 2009 00:13 "David W. Fenton" <XXXusenet(a)dfenton.com.invalid> wrote in message news:Xns9CBDCEFF45EEFf99a49ed1d0c49c5bbb2(a)74.209.136.93... > "Albert D. Kallal" <PleaseNOOOsPAMmkallal(a)msn.com> wrote in > news:QBqJm.2507$rE5.2452(a)newsfe08.iad: > >> "David W. Fenton" <XXXusenet(a)dfenton.com.invalid> wrote in message >> news:Xns9CBCC354C8849f99a49ed1d0c49c5bbb2(a)74.209.136.91... >> >>> >>> How else can you figure out what's not going to work as well in >>> the browser as in Access itself? Surely you're not claiming that >>> 100% of an Access app is going to convert to the browser-based >>> Sharepoint version and have exactly the same performance and ease >>> of use? >> >> Well, actually, yes I kind of am making this claim. > > But in other posts you're saying something completely different, > that only the forms created in Access as web forms are converted. > That is correct, a form designated as a web form, when published gets converted into a web browser form (all that cool java + xml and it is asynchronous). However that SAME form when run in the access client runs and looks and feels just like a desktop form. So those web forms run perfectly fine and look JUST like a regular access forms when you run them in the access client (desktop). In fact, just looking at those forms you can NOT tell it is a web form. So, yes, the forms you build for the web look and feel like any access client form and launch perfectly normal on the desktop inside of access. this includes sub forms, and continuous forms that are designated as web. those sub forms and continuous forms will make the trip into the web... Watch that video again. All the forms you see in the CLIENT are set as web forms. You see some SAME forms used in the client, and then you see the same form running in the browser. For example when I launch the room configuration system that is a continuous form, you see a row of repeating buttons, and you see a row of repeating pictures etc (standard continues form with repeating data). Watch the video,t hat SAME form runs in the browser... All, I repeat ALL of the forms you see running in that demo are marked as web forms. Take a look at the video again. Even the main form that set as the tools->startup form is a web form. Ask yourself how could I develop an application before I ever published it? Think about this for a second. I had that application up and running perfectly normal on the desktop nearly a month before I ever published it. As long as you restrict to web forms, then that application will run perfectly normal on the desktop, or when you publish it, so yes I'm saying you can develop 100% on the desktop and when you publish it you pretty much guaranteed it's going to work the same. Those web forms will look and feel just like a regular access forms when run on the desktop. The whole idea here is that you can use the web form in your desktop application. You don't need "two" forms, one for web, and one for local. In fact you can even execute an open form from VBA and openform works fine if you feed it a web form name. as mentioned, you can have a mix of VBA forms, and web only forms in the same application. When you publish the application, those web forms will make it up to the web, and they'll run and render in the browser with very high fidelity. You'll be hard pressed to tell the difference here. As I mentioned, that includes the continuous forms and the sub forms, take a look at the video again. > > But the widgets in web browsers simply suck, even when extended with > AJAX. > > And continuous forms? Hello? > Watch the video again please...Take careful note of the forms in the client, and then the same continues forms running in the browser. They are the SAME forms. What this means is the forms you see running client side are set as "web" forms. > Can you write macros that are shared > in multiple forms (i.e., not embedded) and those will be uploaded > and used appropriately? Or are you limited to the embedded macros? Access has always had the above feature. You just create a macro and it appears is the standard macro tab. > But it's not your Access forms, but your Access *web* forms that > you're talking about. Yes, but those forms created and designated as web forms make perfectly acceptable and reasonable client forms to use and run and develop with locally on the desktop. So when I said it created a full blown application on the desktop, I did, but the forms I choose to build where web ones. As I said, it's a rather remarkable development paradigm because you can develop as you always done on the desktop, you just have to use the web feature limited forms and you good to go. However, to be clear, you have to set/create the form from the start as a web form. > > But have you addressed the question about the differences between > the free version available on Office Live, the pay version hosted > there, and the full Sharepoint server hosted locally? Are they > identically in functionality for a single user? The above issues are not set in stone yet (too early). However, I'm making the assumption that since office live (small business) had SharePoint services + access services free for the past two years, then I making the assumption that the next version of office live will also have these access services. If you've ever launched a share point list in small business live, you'll see that even in a web browser in table view, when you see that table, in the upper left hand you see an access icon. It been that way when you launch the browser in SharePoint, or office live for two+ years that way now. -- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKallal(a)msn.com
From: Albert D. Kallal on 9 Nov 2009 00:57 "David W. Fenton" <XXXusenet(a)dfenton.com.invalid> wrote in message news:Xns9CBDCC7B4EB9f99a49ed1d0c49c5bbb2(a)74.209.136.93... > This is a crucial problem as IIS still keeps having major > security issues over and over again. It's simply not ready for prime > time as an HTTP server. You 100% complete lost me here. All of those major ISP's offer windows IIS. A rather big portion of my clients are using windows hosting since I require them to use ms-sql server for my software. Any security issues and problems I never heard about, and it would be really amazing that Dotster, Go Daddy and EVERY OTHER MAJOR hosting company on the planet offers cheap affordable and widespread use of IIS and windows hosted web sites. These providers have BUCKETLOADS of customers using IIS and they NEVER have any problems. Now of course since the web site is being hosted, then any problems are that of the hosting company. If these large hosting companies have so much security issues, then how can they offer such cheap web hosting then? As I said, in MOST cases their pricing is so close to the FOSS offerings as to not be an issue. None, not one of any customers or anyone I EVER talked to tells me they have any difference in security issues by placing their web site on a $7 Linux host or a $7 windows host from ISP's like Go Daddy etc. They all offer both choices, and the security issues have been a\ non issue for years for anyone I ever talked to... -- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKallal(a)msn.com
From: David W. Fenton on 9 Nov 2009 14:55
Bob Alston <bobalston9(a)yahoo.com> wrote in news:WMKJm.4508$We2.3055(a)newsfe09.iad: ><David Fentom wrote: > ><But I haven't had contract for a build-from-scratch brand-new >Access <app of any degree of complexity in over 5 years -- all my >work now <is maintaining the apps of my existing client base, and >taking on <new clients with existing apps that need to be revised, >updated and <expanding. > > Perhaps then your Access business is dying. I spend the vast majority of my billable hours on Access, just not new applications. I think one of the issues may be that Office 2007 has not been widely deployed, and thus the new development that usually comes with a paradigm-shifting new version of Access has not happened because people aren't using that new version of Access, because they are resisting the whole of that version of Office. I think that Win7 and the forthcoming Office 2010 is going to change all of that. I'm certainly bullish on Win7 whereas I was completely against Vista. I do fear that many of my clients will resist the ribbon. I am still at the stage of finding it to be amateurish and distracting. It's not persistent enough or uniform enough for me to feel comfortable with it, but, again, I'm not using it all day long, so I'm not really giving it a chance. But it really is a big stumbling block for certain kinds of users, seems to me (and I have lots of them). I mean, I have a client who (rightly, in my opinion) is still upset by the transition from Word 97 to Word 2002/2003 -- the whole task pane thing is still giving her fits (it gives *me* fits). I am also still annoyed at the moving around of features (usually to incorporate them into the task pane). Editing a style was hard enough in Word 97. Now it has twice the number of steps to get to the editing dialog. I haven't looked at Word 2007 to see if it's better organized with the ribbons -- ah, yes, they've made it vastly easier (better even than the Word 97 version), by simply adding a MODIFY button to any place where you select a style. Once there, it's the same old problem with having to dig down through dialog levels off the format button, but at least it's much quicker to get there. That's the kind of thing I can sell with training, but my users will say "but I already know how to do it -- what am I gaining by switching beyond the need to relearn everything?" And in most cases, particularly apps like Word, it's a pretty hard sell. ><Nobody is asking for web deployment. > > I hear of lots of people asking for web development. something > that to date I have done very little of. so David, perhaps they > know you are Access focused and look elsewhere for web > development. I do web development as well, so that doesn't seem to me to be the issue. Now, for significant web projects, I usually direct them to someone who concentrates on web development (and act as the liaison guiding the project, i.e., insuring that what gets done is actually what the client asked for and needs), but that doesn't mean they don't ask me about web development. My main role with most of my clients is to be their one-person IT department, and that means all the IT questions come to me. So, if they were needing web deployment (or something that could be addressed with web deployment), I'd be hearing about it. Of course, a lot of the needs that web deployment is usually an answer to are addressed for *my* clients with either Remote Desktop to user workstations or to Windows Terminal Server. So, I think both of your responses are incorrect. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ |