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: Albert D. Kallal on 4 Apr 2010 18:45 "Salad" <salad(a)oilandvinegar.com> wrote in message news:5audnbIN0-avlyTWnZ2dnUVZ_qednZ2d(a)earthlink.com... > Development in >> .net is significantly more expensive. On the other hand if those >> developers are really talented developers then they might be able to >> offset some of those increased costs. However, I know of many companies >> that by decree from some department state that they don't want to use >> Access anymore because it doesn't perform well or they have trouble >> supporting the application. They then turned to .net, and realize how >> much more expensive it can be. >> > 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! I REALLY do sympathize with you here. > I won't fight against their IT guy. I'm just a developer, he has the > power. I think the company will be impressed with their bill for the > upgrade. They've been tightfisted financially in my7 experience, this > should be an interesting experience for them. > and, you can't fight, that's not productive anyway. 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. > > Not my app. Like I said, the only thing I saw (heard from key user) that > was slow was the reporting process. I told her a $20/memory upgrade would > help her a lot. It often makes no sense, but they blow big huge wad a cash on re-developing in .net, and for what resulting benefits? If the IT department was so good, how come they never built this thing in the first place??? You can't rock the boat here as you suggeston (and that is smart on your part). However, you can suggest some ideas, such as moving to sql server, or terminal services. That is much less costly then re-developing and it often solves all of their business needs here. And, if they going to spend large amounts on .net, then why not get them to spring for sharePoint services and you can do your self as web based in Access! Anyway, good luck. All I can say is do feel free to ask more questions here in this NG. I shall make honest efforts and suggestions to come up with anything that helps your case. 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. -- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKallal(a)msn.com
From: Tom van Stiphout on 4 Apr 2010 23:23 On Sun, 04 Apr 2010 14:26:33 -0700, Salad <salad(a)oilandvinegar.com> wrote: Some problems can MUCH better be fixed by Dell than by expensive consultants. Can you bring in a fast computer for one day for her to work on? BTW, it is always worth doing a real-world test. I recently guessed that a hybrid VB6 + .NET WinApp on 6 year old hardware would benefit from boosting memory from 1GB to 2GB. We temporarily took the memory from one machine and added it to another and re-ran our tests: only a very minor performance benefit. -Tom. Microsoft Access MVP >Bob Alston wrote: >> Salad wrote: >> >>> A company that I'm doing a couple of projects for have a main >>> application written in Access for their production side. It maintains >>> the employee and customer tables and schedules their technicians. >>> >>> Their reports are written to Excel, not using the report writer. If >>> they used a report writer the reports would take a few seconds to >>> process but they pass the report on to the clients and not all of >>> their clients may have Access but would have Excel. >>> >>> They want to port the application to SQL server. And then convert the >>> application to the web using ASP.Net. They say the current system >>> bogs down when they have around 20 users on the system. I noticed in >>> the past that a key user of the application has less than 500K memory >>> so perhaps delay is from the memory, not the app. The user can't open >>> up multiple copies of the app, maybe run a report in the background >>> while working in another copy probably due to the memory limitations. >>> >>> Will converting the application to ASP make it faster? Would it be a >>> major undertaking or are there programs that can make the designing of >>> the app in ASP a simple process? >>> >> Converting to ASP means a complete rewrite. >> >> Is it that all users on the system slow down when there are about 20 >> users on the system or is it just the one user you mention. 500K memory >> is insufficient. They need more!! >> >> Bob > >I really don't know if all users are slow within the app. I know that >the user I mentioned is a key user. Why she has a slow computer is >beyond me. Thanks for your input.
From: Roger on 5 Apr 2010 05:55 On Apr 4, 5:52 pm, Salad <sa...(a)oilandvinegar.com> wrote: > Albert D. Kallal wrote: > > > Salad" <sa...(a)oilandvinegar.com> wrote in message > >news:Pv2dncQMSK2JQCXWnZ2dnUVZ_uCdnZ2d(a)earthlink.com... > > >> A company that I'm doing a couple of projects for have a main > >> application written in Access for their production side. It maintains > >> the employee and customer tables and schedules their technicians. > > >> Their reports are written to Excel, not using the report writer. If > >> they used a report writer the reports would take a few seconds to > >> process but they pass the report on to the clients and not all of > >> their clients may have Access but would have Excel. > > > Any particular reason why some format like PDF is not being used? There > > several free PDF solutions, and for access 2007, PDF support is natively > > built in without even adding any third party tools or downloads > > (assuming you have office sp2 or later). > > This app wasn't written or modified by me. If one could do a table of > contents in a PDF that would jump to a page, that probably would be OK. > Typically, a schedule will have around 30 worksheets in a month; 1 per > day, and all schedules for a day in one worksheet. It's simply clicking > a tab to see what is going on. In an MS Access report, the processing > takes a couple of seconds. Writing to Excel takes longer due to the > format...one can't write them in a group, that'd be nice, and it's > simply due to the layout and formatting of the report. I think if one > could write a TOC in a PDF or have tabs like Worksheets in Excel in a > PDF that'd work. > > >> They want to port the application to SQL server. And then convert the > >> application to the web using ASP.Net. > > > Ok, so they are talking about about dumping ms-access. > > Yes. > > Development in> .net is significantly more expensive. On the other hand if those > > developers are really talented developers then they might be able to > > offset some of those increased costs. However, I know of many companies > > that by decree from some department state that they don't want to use > > Access anymore because it doesn't perform well or they have trouble > > supporting the application. They then turned to .net, and realize how > > much more expensive it can be. > > 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. > > > > > > >> They say the current system bogs down when they have around 20 users > >> on the system. I noticed in the past that a key user of the > >> application has less than 500K memory so perhaps delay is from the > >> memory, not the app. The user can't open up multiple copies of the > >> app, maybe run a report in the background while working in another > >> copy probably due to the memory limitations. > > > In every application I have ever looked at, the vast majority of > > performance is that of good designs vs that of bad designs. We see > > weekly posts in the SQL server newsgroups that when people move their > > data from an access backend to that of SQL server, the performance > > actually slows down. On the other hand, if you know how to use SQL > > server properly, then SQL server will generally run absolute circles and > > beat the pants off an access database runnong over an network if you > > know what you are doing. > > It seems to work quickly the times I've seen it in action. The only > complaint I've heard on speed is the processing of reports...the writing > to Excel. I've heard the reports take about 3 hours (not one, a bunch) > to process each day. And they gave the key player a machine that can't > load multiple copies of Access (at least so she says) and she has less > than 1/2 meg of memory (quite a lot if we were still in DOS, not so much > in Windows). > > > > > > >> Will converting the application to ASP make it faster? > > Well, it doesn't make it faster unless the people who are writing the > > application know what the heck they are doing. I once asked an 80 year > > old grandmother if it makes any sense for an instant teller machine to > > download every single bank account into the machine, AND THEN you type > > in your bank account you want to work on? I don't think anybody with > > with any sensible developers deals but think that an instant teller > > should download everything first and then ask what account number to > > work on. Obviously the approach here is to ask the user to type in > > their account number, and then pull down one record. On the other hand > > while everybody can see the obvious solution here, when going to Access, > > I see application after application where forms are bound to large > > tables without any type of where clause when they those forms are being > > launched. I guess I'm saying if a 80 year old grandmother can come up > > with better software designs that supposedly access developer who is > > being paid to do work, then we have a serious problem here don't we? > > > I spend this concept of searching + user interface + reducing your > > bandwidth requirements in the following little article of mine: > > >http://www.members.shaw.ca/AlbertKallal/Search/index.html > > >> Would it be a major undertaking or are there programs that can make > >> the designing of the app in ASP a simple process? > > > Well if you mean that they are re-developing the application from > > scratch? Yes, they are. There's no special automated solution here. > > However, often the greatest value in any application built is all the > > business requirements and gathering and building something that the > > employees need. That information been gathered over time and now > > obviously is a success for this organization, and you've also proven the > > need for this business process. Often a company hires expensive > > developers, they build something, and in fact in almost eight of 10 > > cases, they don't use the resulting product that built. So proof of > > concept prototyping, and gathering the business requirements is often > > the most significant work you do in a software development cycle. > > > Thus, the real value of your application is that it shows and proves > > design and need for that business process within their organization. > > However because you don't have the other skill sets, you're not going to > > benefit from that proof of concept that you've just done for them, are > > you? And worse is those other technologies likely have a much higher > > billing rate in the marketplace. > > > In your situation, what I would do is move the back end to SQL server. > > That would allow you to continue to use the front end as you have now. > > As a general rule if your application is well written then the amount of > > work to move the backend data to SQL server is very small. I've taken > > some pretty large Access applications, and had them up in running in > > just a day of time. The other beauty of this approach is that you keep > > your current business application running, and likely 98% or more of > > your testing application will run without modifications. However what > > this means then is your data is now sitting on SQL server, and they can > > use some web based reporting system for the data. The other issues you > > have scalability and can run 40 users without problems, or you can have > > the website hit and pull data from this application now. > > > Also keep in mind that you don't develop forms in SQL server. So if you > > move your data to SQL server, then you still have to write the code > > somewhere, such as using .net, asp.net web stuff, or even ms-access as > > the front end as you have now. > > > Also SQL server is very easy to get into, and there's lots of free > > eddition you can download to play with and learn. I'd never use SQL > > server before, and well under 2 hours I had some pretty nice stuff up > > and running pretty quick. As a general rule, just learning to setup and > > use tables on SQL server is far less time and far less of a learning > > curve than learning how to use ms access for example. > > > On the other hand, perhaps they are running SharePoint? As you know for > > Access 2010 it has the ability to create web based applications. > > Yes. I've very impressed with your app. But they don't use SharePoint. > I'd want to check out Office 2010 first; port the app to A2010 and > provide some web parts; reporting, to it. It'd be cheaper. But they > are impressed with their IT guy. Maybe they won't be as impressed if > they get a big bill and not the gratification they seek. > > > So maybe a WEB based solution built with the easy to use product called > > ms access that you already know is a possibility here? > > I won't fight against their IT guy. I'm just a developer, he has the > power. I think the company will be impressed with their bill for the > upgrade. They've been tightfisted financially in my7 experience, this > should be an interesting experience for them. > > > I don't think 20 users in an application is too many, but if you've not > > paid attention to make your application perform very well, then that's > > an issue you might want to address. > > Not my app. Like I said, the only thing I saw (heard from key user) > that was slow was the reporting process. I told her a $20/memory > upgrade would help her a lot. The company said no to her in buyting her > new memory, she won't buy it herself, so the bottom line is she'll > remain frustrated until the new app comes in and the company will take > on a large bill.- Hide quoted text - > > - Show quoted text -- Hide quoted text - > > - Show quoted text -- Hide quoted text - > > - Show quoted text - If the IT guy wants to move to sqlServer, you can do that and point the ms-access application to it as to reports, could you not use access2010 to build a web-report that will deploy on a local desktop without using sharepoint ? how are they building excel worksheet, using excel automation ? creating an xml / html text file ? using excel automation is slow, creating a text file is much faster
From: Salad on 5 Apr 2010 10:15 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.
From: David W. Fenton on 5 Apr 2010 19:01
"Albert D. Kallal" <PleaseNOOOsPAMmkallal(a)msn.com> wrote in news:cN5un.26498$3D3.2152(a)newsfe19.iad: > As a general rule, just learning to setup and use tables on SQL > server is far less time and far less of a learning curve than > learning how to use ms access for example. It's a piece of cake if you already know how to build tables and design schemas from working with Access. Otherwise, not so much. That is, I think you're underrating the amount of knowledge and experience you already had under your belt in regard to database design when you first started working with SQL Server. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ |