Access 2010 with Sharepoint 2010
in [Help]
|
From: Salad on 14 Nov 2009 21:15 Albert D. Kallal wrote: > "Salad" <oil(a)vinegar.com> wrote in message news:7smdnZDD9-> > >>Hi Albert. A2003. I logged into OfficeLive > > > You need to use office live small business, office live does not have > ms-access support. > > Here is a discussion and screen shots: > > http://www.utteraccess.com/forums/showflat.php?Cat=&Board=97&Number=1903007&Zf=&Zw=&Zg=0&Zl=a&Main=1886252&Search=true&where=&Zu=120391&Zd=l&Zn=&Zt=bd&Zs=&Zy=#Post1903007&Zp= > > Hi Albert: Thanks for the above link and data on hyperlinks. Now I have SmallBusiness as well. I wouldn't have gotten this to work without that information. I created a small mdb; DB1.mdb with a junk table called Table1. From OfficeLive, I created an apps area called Small Access Test. If I attempt to upload the file within OfficeLive (by selecting Upload and selecting DB1) I get an error. If I open DB1.mdb in Access and select Table1 and do a file export of it to SharePoint and give the URL, it loads Table1 into the application workspace. I then did a File/GetExternalLink and linked to the file and it linked fine. It created a file in the DB called Table1: All Items and it has a new field in it called Edit which is a hyperlink field. Does this seem to be the correct way of doing this? This was in Office 2003, A2007 is at work.
From: Albert D. Kallal on 14 Nov 2009 23:14 "David W. Fenton" <XXXusenet(a)dfenton.com.invalid> wrote in message news:Xns9CC2905F22C6Df99a49ed1d0c49c5bbb2(a)74.209.136.100... > > 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. > Quite true. however, you are then tied into using that querydef. >> 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. Sure, a case can be made that this belongs in some other tier. On the other hand if they come along and build some new service architecture then I don't have necessary to communicate with that particular layer. As long as the data is stored and enforced by the engine level, then it don't matter what tier or service uses that data. In fact, any service can read that data DIRECT and will have the correct result. > > 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? Yes, correct, this is a new column type in ACE. > >> 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. As I mentioned, sure, but then again this is just a long time debate as to if certain things belong in the software side, or at the data side of things. You might not want to be forced to use that middle tier. With this system you don't have to care anymore. Any new system you build can use that new data column. This kind of debate also been a long time sql server debate and that of some saying one should avoid things like triggers and stored procedures as they don't belong at engine level as opposed to the application level. There is a lot of pro's and con's in this debate, almost Like those who debate between auto number primary keys, and that of natural keys, there is a lot of differing opinions on this issue. However, no matter which way people debate this issue, there is still some advantages to be had for this approach and there is a chunk of the IT industry that has adopted this Philosophical approach, especially for cloud vendors. > > I would never recommend to my clients that they host anything > important on such a service. Unfortunately my opinion here does not really matter here or change what consumers and business are doing. I not really giving my opinion here as much as simply making an Observations as to how people are behaving. Millions and millions of people use Gmail. Millions are now placing most if not all of their business processes on systems like eBay. That means pricing, inventory, sales, payment processing = everything they have is on eBay, but they don't complain that it not on their own computer. People are not listing to the recommends not to use cloud systems. L.A. votes to "Go Google"; pressure shifts to Google and the cloud http://blogs.zdnet.com/BTL/?p=26641&tag=nl.e539 I can get 100's of articles like the above in which county's and municipalities and school districts on jumping on this bandwagon. It not me you have to convince here, it is the millions and millions of customers that choosing otherwise that you have to convince. Many people did not believe in the advantages of the GUI, and they not in this business anymore. This is not our choice, and the boat left the harbor. As you point out, there still many applications that are green screen and were never converted. However, the GUI was not a fad. That no question that there's tons of legacy green screen application left over from that era, however we're not seeing you develop a new architectures and there really no new industry work being created for those legacy green screen applications. And, they don't solve any of the new business needs either. The issue is not that there still some green screen applications being used, or that some are still viable, they don't represent anything in terms of creating new work or the future of our industry. people by the millions are making the clout choice, it's not my decision to make here. > 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. > Cloud computing > by definition requires offline editing or it's useless (since you're > dead in the water if the Internet is down) Most business today generally shutdown without their phones, or without electricity . In fact, most of my customers, if their internet is down, they very much can't work and tend to all go home... >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. Yes, but on the other side, there not a architecture that scales to millions of users at a reasonable cost. Sure the customer side gets thin client with TS, but on the supply side it would be far too expensive to have human labor to setup the individual servers etc.. The "new" cloud operating systems such as azure have the ability to censure, build and put on line computers with the correct services you need. They do this dynamic in real time. So, they tend to have a top level system called the "fabric controller" that goes out to the millions of computers, and figures out which ones has the correct services your software needs. If your software needs some particular type of database system such as sql server, then the top level management systems system will go out and get the best available resources that are currently running, and if they're not running, then it'll will start those services up on most readily available computers. Again, all this stuff is not a buzz word, it's a different way and different architecture of doing things and accomplishing that goal which allows you to deliver software as a service **and** supply those services at a very low cost. So, cloud computing is all about utility computing just like electricity is). So, yes, TS has the benefits, but does not have an architecture that truly scales like Amazon's , or Google, or now azure. Those systems are built from the ground up to scale on demand. Here some reading on Amazons service: http://aws.amazon.com/ec2/ and, here is some on Azure: http://en.wikipedia.org/wiki/Azure_Services_Platform -- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKallal(a)msn.com
From: James A. Fortune on 15 Nov 2009 00:29 On Nov 14, 6:31 pm, "David W. Fenton" <XXXuse...(a)dfenton.com.invalid> wrote: > The quote is from a book that was published in 2002. This predates > MS's move to remove VBA from Excel for Mac. You *do* not what the > upshot of *that* was, don't you? > > You're using an old quote from a period when things in regard to > .NET were much more theoretical than they are now, and that quote > seems to me to be one of *wishing* something rather than stating a > fact. > > > Right then -- not at some point in the future. I > > think the existence of such a plan was likely and that it got > > temporarily abandoned. > > I think you've really got the time frame out of whack. A book with a > publication date of 2002 was published in 2001. Thus, its content > predates not just A2007, but A2002 and A2003. Certainly 2002 and > 2003 were surely largely in the can already or feature-complete in > terms of planning, but the differences between 2003 and 2007 are not > in regard to VBA integration, so there's absolutely no evidence of > abandonment of VBA. > > Of course, you could see embedded macros as evidence of that, but I > would say that those are there as part of the integration with > Sharepoint, which seems much more important to Microsoft than > killing VBA in Access. You might see the whole Sharepoint thing as a > path to abandoning desktop Access, but I don't think that's likely > to happen at all. It's conceivable for desktop Access to consist > entirely of the web forms/reports and have only macros and embedded > macros and no VBA, but I just don't see that as very likely, either, > since by doing that, they would basically have re-invented Filemaker > Pro, along with almost all the weaknesses of FM (insufficiently > extensible scripting being the primary lack). > > Why would they do that? > > More likely is replacement of VBA with some for of VB.NET, seems to > me, and that will likely be highly compatible (though not without > major feature sacrifices along the way, no doubt). > > > I have no doubt that Microsoft would love us > > to move to .NET. What I saw at the time was that the direction > > Microsoft was headed was at odds with the existence of VBA. Like > > a politician, they decided to spread out the implementation time > > to make it more gradual. VBA may not be dead, but its heyday is > > over. My guesses were not as far-fetched as you imagined. I > > think your faith in VBA wasn't much better than my guesses. > > Hmm. You said VBA was on the way out, but it's still there, with > more features than it had at the time of the quote you base this on. > It's fully supported. > > You have to make the argument that something entirely unexpected, > the web integration with Sharepoint, is the reason VBA is on the way > out. Well, blind squirrels and stopped clocks and all that, but we > don't even know that is the case. I strongly doubt that MS will > eliminate a scripting language entirely in favor of macros. The > question is what that language will be. I am not so deluded to think > that it will always be VBA, but what I am certain of is that if MS > follows its historical path, whatever scripting platform they > replace VBA with will either be highly compatible, or it will have a > transparent and reliable transition path. Thus, VBA won't be > replaced with Javascript. It might be replaced with VBScript, but > VBScript *is* VB, so that would be no problem whatsoever. You make some good points. I agree that the point in the book was more hopeful than actual. The date of the book, although it weakens the argument, still points to a plan to remove VBA from its pedestal. Maybe it's like what has happened with parallel programming. The new thought patterns required to implement parallel programming efficiently are making older thought patterns passé. Thus, in preparation for the emphasis on parallel programming inspired by research and required by the resulting trend towards many-core CPU's, some of the OOP concepts that worked great for single core processing are starting to be maligned because they actually hinder the move to parallelism. Although VBA is around as much as ever, and is still one of the best RAD languages ever created, it will likely never receive the bulking up that will be required to keep it from retaining many of its current weaknesses. Microsoft would like Access to work without having to resort to VBA at all, but we all know how much poorer Access would be without VBA or some other scripting language. If the desktop and the internet are to look essentially the same to Access, then VBA has to be redone anyway. VBA limits Access to the desktop, and even there it can be a security risk. In spite of how great VBA has been for marvelously extending the capabilies of Access, I think Microsoft's decision to let it die slowly of relative neglect is probably a wise decision, yet one that will eventually cause me to have to take much more time to write code. James A. Fortune CDMAPoster(a)FortuneJames.com
From: Albert D. Kallal on 15 Nov 2009 02:35 "Salad" <oil(a)vinegar.com> wrote in message news:BcidnaMUZumi- > If I attempt to upload the file within OfficeLive (by selecting Upload and > selecting DB1) I get an error. The above is not for putting up access,but is for simply placing word, pictures, pdf files etc. Not sure what you doing or why a simply file upload fails, but this is has nothing to do with up-loading a list/table to SharePoint. If I open DB1.mdb in Access and select > Table1 and do a file export of it to SharePoint and give the URL, it loads > Table1 into the application workspace. I then did a File/GetExternalLink > and linked to the file and it linked fine. It created a file in the DB > called Table1: All Items and it has a new field in it called Edit which is > a hyperlink field. > > Does this seem to be the correct way of doing this? This was in Office > 2003, A2007 is at work. Yes, in 2007, you can also do a up-size, and it will up-load the table + build a link in one step. Also, 2007 supports off-line mode. So, the feature set feels similar to sql server, you can use export to push up a table, but also I often use the sql up-size wizard to push up a table to sql server since it saves the step of having to do the file->external data link. So, yes, the above is how this works..but 2007 is quite a bit nicer in this regards. -- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKallal(a)msn.com
From: David W. Fenton on 15 Nov 2009 17:29
"James A. Fortune" <CDMAPoster(a)FortuneJames.com> wrote in news:a2d9cea4-4e83-43b1-945c-a309ed6f9d09(a)u7g2000yqm.googlegroups.com : > In spite of how great VBA has been > for marvelously extending the capabilies of Access, I think > Microsoft's decision to let it die slowly of relative neglect is > probably a wise decision, yet one that will eventually cause me to > have to take much more time to write code. I think this "decision" of which you speak is a complete figment of your imagination. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ |