Access 2010 with Sharepoint 2010
in [Help]
|
From: Albert D. Kallal on 12 Nov 2009 17:17 "David W. Fenton" <XXXusenet(a)dfenton.com.invalid> wrote in message news:Xns9CC1A44AA8358f99a49ed1d0c49c5bbb2(a)74.209.136.88... > Salad <oil(a)vinegar.com> wrote in > news:ZP-dndDg2u5P7GbXnZ2dnUVZ_g2dnZ2d(a)earthlink.com: > > > I don't know that Albert ever answered my question if there was a > conversion route from standard Access forms to web forms. It's not > like I asked only a couple of questions, so in the flurry of > questions it wouldn't surprise me if some of them just whizzed by > him without registering. > There is not a conversion utility, the feature will not make into the final build (budgets simply are not going to allow this for this version)... > The point is that a properly-designed app will upload. > > But that isn't your existing pre-A2010 Access app. > Correct, I was quite clear, but again to be more clear: you have to create a form that is designated as a web form for the publishing part to work, you can't convert old ones. -- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKallal(a)msn.com
From: Bob Alston on 12 Nov 2009 17:31 > > > There is not a conversion utility, the feature will not make into the final > build (budgets simply are not going to allow this for this version)... > > That is a real shame. Hopefully some enterprising individual will develop a utility and make a few bucks. bob
From: Albert D. Kallal on 12 Nov 2009 18:11 "Bob Alston" <bobalston9(a)yahoo.com> wrote in message news:t10Lm.11024$dc2.7386(a)newsfe20.iad... > > >> >> There is not a conversion utility, the feature will not make into the >> final build (budgets simply are not going to allow this for this >> version)... >> >> > > That is a real shame. Hopefully some enterprising individual will develop > a utility and make a few bucks. > > bob That's would be difficult. However, to get going, you most certainly can and do import existing forms and tables and code modules etc. Those forms will remain VBA, and not publish. At that point, you have an application, and the parts that you want for the web such a bunch of reports for staff or perahps some data gather forms usually go VERY quickly with the wizards etc. In a sense, for existing applications, all the hard part been done, the fun puts are creating some reports and perhaps data gathering forms augment the existing application. At the end of the day, the problem/challenge here is they not just making a form run inside of a browser (you can do that with terminal services). This stuff is built around a scalable true multi-tier web development system. The whole concept of UI and data logic etc. being separate means that really a new approach was needed here. This model and design also bows to cloud computing in a large way, so it really is a paradigm change... -- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKallal(a)msn.com
From: David W. Fenton on 13 Nov 2009 14:09 "Albert D. Kallal" <PleaseNOOOsPAMmkallal(a)msn.com> wrote in news:RK%Km.32682$W77.1138(a)newsfe11.iad: > "David W. Fenton" <XXXusenet(a)dfenton.com.invalid> wrote in message >> >> I just Googled "xml data cube," a term that is 100% meaningless >> to me, and got no useful results. Please explain. > > Google xml and web services and soap.... That still doesn't tell me anything useful. Sounds like just another buzzword. >> 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. > > It is a great idea because it's centralizes your design and > separates it from the UI. That could be claimed for multi-value fields, also, or table-level lookups. It would be more compelling if there weren't already a way to make that separation and maintain consistency, i.e., a stored QueryDef with the derived field. [] > Furthermore what happens if some other SharePoint services needs > to use that Full Name expression?. What happens if the team down > in the IT for billing or the folks working with the sap system > needs that list of customers? Again you get to define how that > field is displayed, and it stored in the data. Then it should be defined in a layer *above* the table, where it belongs. And just to be clear, this *is* something that's both in Sharepoint and in the new version of ACCDB, right? That is, it's a new column type in Access? [] >> 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. > > It might not be a browser that is pulling or using that data. It > might be some other web services. To me, the Access side of this is more compelling than the web side, since I'd assume a complex web platform like Sharepoint would be built with at least a 3-tiered structure, such that nobody but the middle tier running on the server is running in direct communication with the data store. > No matter how you slice this, you still saving > processing by doing this, you still centralizing the one place > where this expression exists and will be maintained. You don't > have to care or worried how some other system is going to pull > data out. You don't know or care of that other system has some > type of expression builder. You data is just sitting there ready > to be used and consumed by any conceivable type of application. That's what the middle tier is for. Obviously, and Access app using and ACCDB back end has not middle tier (it really doesn't have any tiers at all from the standpoint of true client/server), but it does have the database engine at one level and the presentation layer at another. So, I could see your justification being applied to the Access side of things, as multiple apps really would benefit from having it in the only available shared component, the database itself. But for the web, I just don't see the justification for putting it in at that level. > In addition to the above concepts, storing the value scales > better. so I suppose you could have the sharepoint services create > that expression on the fly, but that doesn't scale as well. >>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. > > No, but with cloud computing we are talking about 1 million small > businesses, each with only those 2 or 3 users. At the end of the > day we still scaling out to 2-3 million users here. I would never recommend to my clients that they host anything important on such a service. I don't trust any cloud provider to secure the data or to be able to make and restore backups or to be able to maintain service 100% of the time. So, if I were looking at Sharepoint for a client, it would be on a local Sharepoint server. I can't really think of any reason why any of my clients would ever want to expose the Sharepoint-hosted apps to the public Internet. While I could see using it to provide web interface for customers, I would never deploy that as anything but a VPN-requiring app, simply because I wouldn't want to have to have an SSL certificate (they are expensive). >> 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? > > Well, in fact that where this expression service eventually will > be running. On the other hand, this feature is great and I like > having a handy dandy expression available at the table level even > if you not using sharePoint. Again, on the desktop any other > application can open up the table direct and pull the data out. > That app doesn't have to know if there's some expression service. > The data is just sitting there in the file ready to be taken. As I said above, I think the derived field feature is more justifiable for Access than it is for Sharepoint, though the justifications are different: for Access, it's having a single layer that is accessed by everyone and is consistent, for Sharepoint, it's the scalability issue (though I don't see how this would help that much for any app not used by 100s of users, as opposed to your example of a shared Sharepoint server hosting 1000s of apps). > As I said our industry is going through a really big change right > now, perhaps larger than the change from green screen to the GUI. I don't understand this assertion of yours. None of the businesses of any size that I've had any dealings with have been using green-screen apps for a long time. A whole lot of green-screen apps are still running the same back end, and taking output originally intended for a dumb terminal and presenting it in a web browser, and a lot of them are out there with terminal windows displaying the same output as the dumb terminal. But I would argue several things: 1. in most cases, these back ends are running code that nobody wants to re-architect. 2. for data entry processes, which are largely sequential and repetitive, the green screen interface works extremely well. Hosting the green screen app in a terminal window running on a multi-tasking OS takes care of the problem of running multiple apps for multipler purposes. 3. most of these apps don't benefit from being converted to a web app, except for distributility. And for most such apps, that's already been done. But I don't see anyone but finance-related organizations using these kinds of apps (i.e., green-screen apps running in a terminal window). I'm pretty sure that if converting to a Web 2 interface would provide productivity, the money would be there to make the conversion. > We have to > adjust some of our development practices and programming > approaches. One big reason that is driving this is the success of > cloud based vendors like Google. We see school districts, > municipalities and all kinds of organizations going to software as > a service system and using providers like Google. I think cloud-based computing is too new to declare a success. Remember the history of offshore outsourcing -- many of the companies that offshored their tech support to India brought it back to the US, or left only a shallow first tier of support offshore, and brought back the major part of it to the US (though quite often in some low-cost area like Nebraska). While software as service is going to fit certain kinds of companies, I think it is not going to fit a large number of them. And I also think it's going to be problematic because of latency, even though even Google Apps has certain forms of offline editing. With offline editing and synchronization, you're adding a new layer of complexity to your data storage, and that's another place that something can go wrong. You're also making the interface more complicated for the users, since they have to understand the edit conflict dialogs and act on them appropriately. I've always tried to design my Access apps so that the users never produced any write conflicts so they didn't have to confront the dialog asking them what to do (whether the default one or custom ones). Cloud computing by definition requires offline editing or it's useless (since you're dead in the water if the Internet is down), and that means certain additional levels of complexity for synchronizing data and for the end users. I just don't see the benefit. But then, I've been heavily committed to Windows Terminal Server and remote desktop access for a very, very long time, so perhaps my clients have been getting the majority of the benefits from the standpoint of access without using this particular buzzword technology. [rest snipped, because I've basically already addressed all the main points in what I've written above] -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/
From: David W. Fenton on 13 Nov 2009 14:12
"Albert D. Kallal" <PleaseNOOOsPAMmkallal(a)msn.com> wrote in news:zC0Lm.7157$rE5.2235(a)newsfe08.iad: > Those forms will remain VBA, and not publish. At that point, you > have an application, and the parts that you want for the web such > a bunch of reports for staff or perahps some data gather forms > usually go VERY quickly with the wizards etc. I'm not clear on whether or not forms are different from reports. To reports have to be created as web reports as well? Obviously, a report with VBA or that uses events not supported by the web event model wouldn't work, but it's not clear to me from what you said that you have to branch both of them (or replace the Access form/report with the web version). Have you cited any comparison of the events/properties/features that differ between the web and Access forms? Also, you stated in one post about struggling with getting along without having VBA functions like Date() and the like. Is it not the case that macros fully replace that kind of basic functionality (if not replacing everything you can do in VBA)? -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ |