Converting app to ASP?
in [Help]
|
Prev: Library Reference not recognised - comdlg32.ocx - Microsft Common Dialog Control issue
Next: What do people actually use Access for?
From: David W. Fenton on 5 Apr 2010 19:28 "Albert D. Kallal" <PleaseNOOOsPAMmkallal(a)msn.com> wrote in news:GE8un.92860$gF5.88(a)newsfe13.iad: > "Salad" <salad(a)oilandvinegar.com> wrote in message > news:5audnbIN0-avlyTWnZ2dnUVZ_qednZ2d(a)earthlink.com... >> I think they got a new IT person in. He has determined SQL >> Server and ASP is the way to go. He's got the company ear, I >> don't. > > The above sucks, and I seen it time and time again. The IT guy > craps on Access. They bring in some .net people, spend huge > amounts, and after all is said and done, they have a worse > application, or to they stop the project all together. I can't > tell you the number of times seen or herd this tail. At the end > of the day, they often wind up right back to square one with > someone building something again in access that they needed in the > 1st place, or already had! Back in 2000 or so, a client of mine had a change of management and the person who always hated their really elaborate Access app (that I built) because it didn't adjust to the size of her monitor (ack -- I told management that it could be done, but at a cost, and they decided it wasn't worth it; this was back in the data when a nice new monitor supported something higher than 1028x768, but most of the 2- and 3-year-old PCs maxed out at that). So, they ended up hiring an outside company to (they claimed) webify their app (they had an office in NYC and an office in London and two important offsite consultants, all of whom used the app and Jet replication to synchronize data). Anyway, at a certain point, I was brought in to help the new developers import the legacy data into their app. Talking on the phone with one of the developers, who was really very nice (as most people are), he admitted that the app they had built had about 1/3 the functionality of my Access app, was not "webified" at all, and ran slower than the Access app. He also said he had no idea you could do in Access the things I'd done. The company that hired these developers to replace my app was out of business 18 months later. > I REALLY do sympathize with you here. Me, too. [] > Another REALLY great solution in your case might be terminal > server. That way, no deployment issues, and even the network > bandwidth issue is very much eliminated. And, it centriailzes the > applcaion for the IT deparmtnet liking. I'd still balk at 20 simultaneous editing users with a Jet/ACE back end, unless the front end is more carefully designed than most of the ones I encounter in the wild. I'd go with your recommended back-end upsizing and deploy on Terminal Server, myself. [] > As you say, much of this is beyond your control. My experience > shows these situations so often turn out bad or they work, but > wind up costing the company MORE money then what the solution was > worth. They already have something really good that they paid > money for. Last time I looked software does not wear out. I think many companies completely underrate the importance of the knowledge encapsulated in a pre-existing application. I always stress that when I'm selling a client on reviving a moribund Access app instead of replacing it with something sexier, that they've already invested a huge amount of time and money in building their business processes into their Access app, and if they toss that they may go through a period in which key processes are imperfectly completed (Joel Spolksy's old Netscape article is apropo here). When the problems are basically with performance or scalability, it's almost always the case, in my opinion, that fixing the Access app is way, way easier than porting the whole damned thing to another platform. But most people don't understand that the performance/scalability issues are not some inherent flaw of Access, but specific to the implementation within Access (the front end design, the choice of back end, the interactions between the two). This is because so many of the people in IT are just complete idiots about Access, and, like the developer who admitted the app he'd created was not as good as the one it was replacing, they just don't know any better. Anyway, this is why I fight the good fight on StackOverflow.com and elsewhere, meeting Access bigotry with facts wherever I see it. A2010 is going to be huge in that regard, and I can't wait -- I have at least two clients for whom it could be a huge win, in fact, and I intend to start experimenting and prototyping as soon as I can download the Office 2010 RTM from MSDN! -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/
From: Bob Alston on 5 Apr 2010 20:03 David W. Fenton wrote: > "Albert D. Kallal" <PleaseNOOOsPAMmkallal(a)msn.com> wrote in > news:GE8un.92860$gF5.88(a)newsfe13.iad: > >> "Salad" <salad(a)oilandvinegar.com> wrote in message >> news:5audnbIN0-avlyTWnZ2dnUVZ_qednZ2d(a)earthlink.com... > >>> I think they got a new IT person in. He has determined SQL >>> Server and ASP is the way to go. He's got the company ear, I >>> don't. >> The above sucks, and I seen it time and time again. The IT guy >> craps on Access. They bring in some .net people, spend huge >> amounts, and after all is said and done, they have a worse >> application, or to they stop the project all together. I can't >> tell you the number of times seen or herd this tail. At the end >> of the day, they often wind up right back to square one with >> someone building something again in access that they needed in the >> 1st place, or already had! > > Back in 2000 or so, a client of mine had a change of management and > the person who always hated their really elaborate Access app (that > I built) because it didn't adjust to the size of her monitor (ack -- > I told management that it could be done, but at a cost, and they > decided it wasn't worth it; this was back in the data when a nice > new monitor supported something higher than 1028x768, but most of > the 2- and 3-year-old PCs maxed out at that). So, they ended up > hiring an outside company to (they claimed) webify their app (they > had an office in NYC and an office in London and two important > offsite consultants, all of whom used the app and Jet replication to > synchronize data). > > Anyway, at a certain point, I was brought in to help the new > developers import the legacy data into their app. Talking on the > phone with one of the developers, who was really very nice (as most > people are), he admitted that the app they had built had about 1/3 > the functionality of my Access app, was not "webified" at all, and > ran slower than the Access app. > > He also said he had no idea you could do in Access the things I'd > done. > > The company that hired these developers to replace my app was out of > business 18 months later. > >> I REALLY do sympathize with you here. > > Me, too. > > [] > >> Another REALLY great solution in your case might be terminal >> server. That way, no deployment issues, and even the network >> bandwidth issue is very much eliminated. And, it centriailzes the >> applcaion for the IT deparmtnet liking. > > I'd still balk at 20 simultaneous editing users with a Jet/ACE back > end, unless the front end is more carefully designed than most of > the ones I encounter in the wild. > > I'd go with your recommended back-end upsizing and deploy on > Terminal Server, myself. > > [] > >> As you say, much of this is beyond your control. My experience >> shows these situations so often turn out bad or they work, but >> wind up costing the company MORE money then what the solution was >> worth. They already have something really good that they paid >> money for. Last time I looked software does not wear out. > > I think many companies completely underrate the importance of the > knowledge encapsulated in a pre-existing application. I always > stress that when I'm selling a client on reviving a moribund Access > app instead of replacing it with something sexier, that they've > already invested a huge amount of time and money in building their > business processes into their Access app, and if they toss that they > may go through a period in which key processes are imperfectly > completed (Joel Spolksy's old Netscape article is apropo here). > > When the problems are basically with performance or scalability, > it's almost always the case, in my opinion, that fixing the Access > app is way, way easier than porting the whole damned thing to > another platform. But most people don't understand that the > performance/scalability issues are not some inherent flaw of Access, > but specific to the implementation within Access (the front end > design, the choice of back end, the interactions between the two). > This is because so many of the people in IT are just complete idiots > about Access, and, like the developer who admitted the app he'd > created was not as good as the one it was replacing, they just don't > know any better. > > Anyway, this is why I fight the good fight on StackOverflow.com and > elsewhere, meeting Access bigotry with facts wherever I see it. > > A2010 is going to be huge in that regard, and I can't wait -- I have > at least two clients for whom it could be a huge win, in fact, and I > intend to start experimenting and prototyping as soon as I can > download the Office 2010 RTM from MSDN! > Well said. Here here! bob
From: Albert D. Kallal on 6 Apr 2010 02:02 "David W. Fenton" <XXXusenet(a)dfenton.com.invalid> wrote in message > Anyway, this is why I fight the good fight on StackOverflow.com and > elsewhere, meeting Access bigotry with facts wherever I see it. > I suspect that you're not interested in a Ford versa Chevy type discussion at all (we got over that kind of thing in grade school). However, when criticism becomes unfair it can have a real bottom line effect on adoption and use of product that I have a considerable amount of investment into. Including a number of products that are sold not as being Access based, but simply as a solution into particular marketplaces. How IT views access can thus really affect my bottom line. Access has its warts and problems like any product, and I don't mind criticisms of shortcomings, I really don't. However, when people dump on it because they don't understand the product, then that's when I raise my hand. I often let things go in this NG. On StackOverflow I tend to be quite a bit harsher, because there's more developers there. In the newsgroups here, we're often helping new and frustrated users, and they just trying to get some work done. They don't know a lot about other products. On stackoverflow, it's full of developers, and that criticism is often unfair. > A2010 is going to be huge in that regard, and I can't wait -- I have > at least two clients for whom it could be a huge win, in fact, and I > intend to start experimenting and prototyping as soon as I can > download the Office 2010 RTM from MSDN! I really like some of the aspects of the new system (I sure you figured that out!!). From an early point on, I actually liked and embraced the idea SharePoint is a good thing to be a part of. I think it's important to note, that for organizations that have SharePoint, and they tend to be the ones with good money, this opens up a lot of doors for Access and Access developers. And it also opens up the doors for access to be adopted again in corporate environments where might not have been. And for the first time in probably 15 years, there's even a video posting on the Access blog where Microsoft is internally using some Access applications build. This is great news. However, for public facing WEB based applications in environments where customers don't have SharePoint? Then I think this issue has a lot more serious downsides. I as a general rule can't just go to a customer and sell them SharePoint for ONLY a few web based forms, and while hosting is an option, it's not a great option for anonymous users. The result here is I am not really sure if I will ever wind building applications for the WEB that are "public" facing with access. On the other hand I had a good conversation with the folks at www.Accesshosting.com. I stated to them that it is VERY much worth it for them to try hard to give anonymous usage and to eliminate the need to log into any website we build. They already came back to me and said they believe they have a working solution for me. And to be fair, SharePoint itself is receiving major upgrades and benefits to better support public facing web sites with SharePoint 2010. However the design philosophy and idea of an anonymous web site is not really for all those cool SharePoint workflow and other features such as Access web stuff. Of course the problem here is the philosophy behind Access is not designed around you having to build and set up your own user logons. when using the SharePoint logon system, then everything's fantastic. One of the great things about the new asp.net tools is it assumes and realizes that most developers are going to have to setup and build some type of user logon system on a web site. Therefore it comes with a whole bunch of wizards and setups to make this really easy. And they've even tided into the user security roles when you're using SQL server. This also enables you to set up things such as having certain buttons and things disabled on particular web parts with GREAT ease. Again it just comes down to the philosophy of design from the early days, and what the average user is going to be doing with an asp.net web site. Because the user authentication, and sign up in Access WEB is totally based around the SharePoint setup, then this is really great as it frees you from having to bother with this issue for each little WEB based application you write and deployed within the organization. So in this type of scenario, being married to SharePoint is really great. The above issue is just like how VB6 was good for un-bound forms because they had tons and tons of wizards that would help you build and connect to data. However when you come from VB6 and you jump into Access development, and you start trying to build all your forms as unbound, you get the worst of both worlds, because Access doesn't have tons and tons of wizards to try and help you work with un-bound forms. And, even worse is that our bound forms has a huge number of events and features setup around the idea and concept of bound forms. If you go un-bound in Access, you have to give up most of those features + not having wizards + support tools. The above is not a huge deal. However, the above points out why Access for the web is somewhat weak in terms of setting something up and having to build your own logon system. With asp.net there's a great set of wizards and wide sweeping support that permeates through the whole development process because most developers know when they're building a website, they going to have some type of logon system. I can't think of any usable web application that doesn't have some type of log on system. What's interesting, is I think for a lot of types of applications, the Access WEB development system is actually the best and quickest development tool for SharePoint applications - it's the first real RAD WEB based tool for SharePoint. I also think what's really fascinating is that the Access application can be set up as a SharePoint "template" that people throughout the organization can use to create a web site for their own purpose based on that application (the Access web application in fact becomes a whole little website or so called sub-site when you do this on SharePoint). I am kind of at a crossroads here: For SharePoint environments, Access is a winner. No question. For public facing WEB type stuff, I'm really torn here. I'm not really sure it makes a lot of sense to build a logon system in access WEB. If the folks at Access hosting come up with fairly affordable monthly rate, then yes I will spend a day building some type of logon system with all the little logon forms and the "I forgot my password" email me stuff. However if they're not really affordable rates, then I stick to using Access WEB for SharePoint customers, or using Access hosting for those customers that still have internal staff and logons are required and controlled by the staff for their organization itself. However, for public facing web sites where the customers can create and setup their own login and signup process? Right now, my bets are that I will be using asp.net for this type of application. -- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKallal(a)msn.com
From: Roger on 6 Apr 2010 04:30 On Apr 5, 10:15 am, Salad <sa...(a)oilandvinegar.com> wrote: > Roger wrote: > > > If the IT guy wants to move to sqlServer, you can do that and point > > the ms-access application to it > > That could be done. I don't know if that would improve the speed of the > application. > > > as to reports, could you not use access2010 to build a web-report that > > will deploy on a local desktop without using sharepoint ? > > I think so but the files aren's just for internal use but for the > external clients as well/ > > > > > how are they building excel worksheet, using excel automation ? > > creating an xml / html text file ? > > Using automation. > > > > > using excel automation is slow, creating a text file is much faster > > I know. Creating the report thru the Access report writer is extremely > quick. I think they like just hitting a worksheet tab in Excl and > viewing the daily data per worksheet instead of scrolling thru pages and > pages of a report. I doubt they'll get that flexibility using ASP either. moving the application to sqlServer may or may not improve performance, but it does give the IT guy the perception of a 'win' on his check list give you another tool to optimize linked views if performance is an issue it seems that part of the app is slow due to the creation of internal / external worksheets due to automation. If you saved one of the worksheets as an xml document, and then changed the creation process to create text based, xml-document, would that improve that portion of the creation process enough for it to become a non issue ?
From: Banana on 6 Apr 2010 08:08
Albert D. Kallal wrote: > For public facing WEB type stuff, I'm really torn here. I'm not really > sure it makes a lot of sense to build a logon system in access WEB. If > the folks at Access hosting come up with fairly affordable monthly rate, > then yes I will spend a day building some type of logon system with all > the little logon forms and the "I forgot my password" email me stuff. > However if they're not really affordable rates, then I stick to using > Access WEB for SharePoint customers, or using Access hosting for those > customers that still have internal staff and logons are required and > controlled by the staff for their organization itself. I have a suspicion that's more or less intended, for same reasons we don't really see shrink-wrapped Access applications (not to say there aren't, just not many and usually for specialty market). I'd wager that large majority of Access applications out in wild are in-house applications of some kind and have no public face at all. That may be what they likewise thought for Access Services - for a company's intranet or at least garden-walled internet so their traveling salesman can go to a wireless spot and do their synchronization... still not exactly public-facing even though it's internet-accessible. > However, for public facing web sites where the customers can create and > setup their own login and signup process? Right now, my bets are that I > will be using asp.net for this type of application. One more point. Let's say a company want a public facing website... maybe to assess their products out in wild - they would almost certainly get a better deal both in terms of time and money if they used say, monkeysurvey.com or similar sites which does wonders in simplifying setting up a survey for people to take and once done, download the data into various format. I've used that and it's quite slick and easy to do that without any web programming. This easily clean the floors against Access Services, including pure ASP.NET and the services can be either free or for a small fee. I don't know if there are other similar sites for different purposes but when I think data-centric + public-facing + internet-accessible, it almost inevitably will be some kind of survey. I guess the other possibility is reporting but not certain about that. So, I don't know what Microsoft was thinking WRT Access Services, but I don't think they really had intended it to be public facing any more than the traditional Access applications were so that may be more or less a moot point in a sense of speaking. |