Access 2010 with Sharepoint 2010
in [Help]
|
From: David W. Fenton on 12 Nov 2009 16:08 Salad <oil(a)vinegar.com> wrote in news:ZP-dndDg2u5P7GbXnZ2dnUVZ_g2dnZ2d(a)earthlink.com: > 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? One thing I learned from my exchanges with Albert in the last few days is that you can't do this with an existing app -- the app you publish to the web has to be designed with the web versions of the Access objects. 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. The point is that a properly-designed app will upload. But that isn't your existing pre-A2010 Access app. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/
From: Albert D. Kallal on 12 Nov 2009 16:11 "Salad" <oil(a)vinegar.com> wrote in message > 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. Actually, why wait? Note that for the free SharePoint stuff, you need office live small business, office live does not have the access stuff. So, no need to wait, start reading up on SharePoint now... If you have access 2003, or better access 2007, then start playing with the SharePoint stuff now. That is the whole suggesting here. Simply try upsizing some small tables from access to that SharePoint site. See how it all works. Try the "off line mode"...and try the on-line mode for 2007. So, gain some experience to upsize access 2007 tables to SharePoint. The wizard and steps are very much the same for publish in 2010 as they are for up-sizing tables in 2007. So, then when you get your hands on a2010, then all that time spent learning how to do this in a2007 will prepare you for a2010. Then, you be ready without having two learning curves occurring at the same time. It will be less then 5 minutes affair of your time to start publishing applications... > Your prediction; early, mid, or late 2010? I can only guess, but my guess is mid 2010 at best.. -- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKallal(a)msn.com
From: David W. Fenton on 12 Nov 2009 16:11 "Albert D. Kallal" <PleaseNOOOsPAMmkallal(a)msn.com> wrote in news:F5OKm.4853$dc2.3463(a)newsfe20.iad: > 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. I assume you replace all of this stuff with macros, right? -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/
From: James A. Fortune on 12 Nov 2009 16:56 On Nov 12, 4:11 pm, "David W. Fenton" <XXXuse...(a)dfenton.com.invalid> wrote: > "Albert D. Kallal" <PleaseNOOOsPAMmkal...(a)msn.com> wrote innews:F5OKm.4853$dc2.3463(a)newsfe20.iad: > > > 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. > > I assume you replace all of this stuff with macros, right? > > -- > David W. Fenton http://www.dfenton.com/ > usenet at dfenton dot com http://www.dfenton.com/DFA/ In: http://groups.google.com/group/comp.databases.ms-access/msg/65f3941f7de8a50a David Fenton said: >CDMAPos...(a)FortuneJames.com wrote in >news:1140552410.467804.115390(a)o13g2000cwo.googlegroups.com: > >> Stephen Lebans wrote: >>> James where in the world did you read that VBA is no longer >>> available with Access 12? Do you know how ludicrous your >>> statement is? > >> Whew. I'm glad it was ludicrous. I thought VBA was history. > >Do you realize what a dis-service you've done to this newsgroup by >posting the things you've posted here? You've created a set of >rumors that someone searching Google Groups may encounter, which may >end up as misinformation that propagates far beyond this particular >thread. > >If you didn't have any actual proof for any of your assertions, then >you shouldn't have made such ridiculous statements. > >I'm beginning to recall now why I had killfiled your previous email >address. I haven't yet decided if I'll be plonking this one, too. > In: http://groups.google.com/group/comp.databases.ms-access/msg/d1ad8db081df7fdd I quoted from Jeffrey Richter: ....Visual Basic .NET (which now subsumes Visual Basic Scripting Edition, or VBScript, and Visual Basic for Applications, or VBA)... so perhaps the idea is not as ludicrous now as it was back then. With the benefit of hindsight, I see that the parts where I guessed incorrectly were based on my lack of understanding about how Access handles code internally. I also see that some of my other guesses weren't so bad. James A. Fortune CDMAPoster(a)FortuneJames.com
From: Albert D. Kallal on 12 Nov 2009 17:11
"David W. Fenton" <XXXusenet(a)dfenton.com.invalid> wrote in message > > 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. Right, but all of the web services and soap protocol's MOSTLY use xml. So, there is problems here, and we talking about web services here. Obviously the cr+lf issue was addressed, but there are issues when pumping data (tables) as xml data. > > 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). Well, actually cr+lf's don't behave well in a table of data that is xml. It often a problem for data going either way..... > > 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.... > > > 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. No question that you might want to build one query, and then from that point on make sure that every other query you build is based on that one query. Unfortunately that's not always practical, and that's not always the choice developers make during the designing of their applications. If I change that full name field, every other object in the database from many queries to many reports to many forms will ALL benefit from this change instantly. 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. Now your access application on the desktop, the web server, and the IT group of .net developers, or even the SharePoint work flow management system can simply use that column fullname in their web services. They can all pull the data from that table and you can be assured that the FullName column is the same for everyone. You can't really assume that every other workflow and Smartphone using that data will necessary be using sql to get that data (they likely be using some web services). Storing the expression means that everyone can use it. We really don't care what kind of technology is going to pull out and use that data, but the data is in the table in the way that everyone can use it. > > 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. 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. 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. > > 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 our industry is going through a really big change right now, perhaps larger than the change from green screen to the GUI. 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. Just last week I sold a client on one of my software packages. The client is a small startup with two users and a small office. They are istalling the access application on their two computers, but I am hosting the data on SQL server for them. The software sale was easy and quick and they don't even have a file server as yet...and I don't care.... These cloud provdiers might not be as good as the desktop software, but that's the same thing when mainframe people were saying that those desktop computers are not reliable enough. Desktop computers were not reliable as mainframes, but most businesses didn't care because it was cheaper and easier. Telling the small business that they don't have to hire that expense of little nerd kid with funny glasses to come around and upgrade their software on their computers is a big selling point. This is what is selling those school districts on this stuff (no more $$ to the the evil software companies for upgrades). Telling them that you can get rid of these expenses is a huge selling point, so Right now in the marketplace cheap and easy is what sells. I don't think the software systems are the best, but they're cheap and easy. I don't think McDonald's is the best food in the land, but it's fast and easy and available, and again that's what sells in the marketplace. > [] > >> 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. Well as mentioned, see my other example in this thread, you might write a complex payroll system with all kinds of complex code and VBA. However the part for employees to check their holiday pay, enter their time sheets, or perhaps choose when they are going to take time off work is ideal for access. The same goes for any complex access application, there still might be some invoicing or scheduling information, or even balance owning or pricing informaton that longtime customers would really benefit by placing that information up on some little customer "self serve" web portal. why not let them check this inforaton instead of phoning up a staff memeber to accomplish and look up the information in which the customers essentially should be able to do this themselves? In fact pretty much most of my clients could use some type of customer serve web portal for least some of the data in those access applicaons. In other cases like the payroll system example, then again employees could help themselveto some of the data that resides in those access applications, but there is no need for, and in fact it's far better for them to not have them have install or use the MS access applicaion... -- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKallal(a)msn.com |