Susan Harkins
ssharkins at bellsouth.net
Fri Mar 19 17:20:40 CST 2004
Drew -- this really isn't in response to your post, but just a general question that relates more back to the original problem -- kind of.. Does the Snapshot Viewer control solution have some advantage over XML? Since Access automatically generates web-ready files, I'm curious why someone might choose the control solution instead. It's easy to pull together, but so is an XM-based solution. Is there some advantage. Susan H. I have a personal side project I call 'wolfweb'. It was built for displaying Access reports on the web. My company has several 'report' databases. One such database has about 900 reports. Most of these reports prompt the users with dialog boxes. The problem with taking a database like that to the web, is that you have to rebuild every report, in order to get around the dialog boxes. I did about 4 or 5 reports like that. Took two to eight hours a peice. I had to rebuild the query behind the report (along with some report modification), then build an ASP page to ask for the criteria. Doing that for 900 reports was not going to work. While it may have provided job security until I was 50, it would have probably killed me long before then. So I built wolfweb. WolfWeb is a multi-threaded VB program. Here's how it works. The first ASP page asks for what database you want to use. (In the working copies of wolfweb, the db is hardcoded...). Once it knows the database, the next asp page displays two combo boxes, one for the report (which lists all of the reports in the database), the next is the format that you want the report displayed in. When you select those, and continue, WolfWeb (which I have running on a separate machine from our Intranet (where the ASP pages are residing) goes and opens an instance of Access, and runs the report. At the same time, it starts another thread, which watches the Access window. When it 'sees' a dialog window open for the Access Window, it 'diagrams' it, and sends that back to the requesting asp page, which then builds an exact 'HTML' version of the dialog box. The user can then enter what they want into the HTML 'dialog' box, and when they submit that, their data entry is replicated on the WolfWeb server (by the watching thread), and the process continues until the report is created. Then the asp page redirects to the new 'temp' file which is the report saved in the format of their choice. Works like a charm. Only known bug is that if the dialog windows are interacted with the Enter key, instead of a mouse click, it gets goofy. I already have a little Java script to disable the enter key (in fact, wrote it working on the AccessD archives), just have never gotten around to implementing it. WolfWeb has been running here for over a year now, without any real hitches. The BIG catch, and the reason I never finished it to sell it as a completed product, is the fact that Access doesn't treat it's forms like normal windows. WolfWeb eats through dialog boxes (criteria prompts, login prompts, etc....(the two databases wolfweb is running for are both reporting engines for an Oracle database, and WolfWeb handles the ODBC login just like any other dialog window...), however, if a form is used for the reports criteria, it will just prompt the user as if the form isn't open (which it isn't). I figured out that instead of dealing with the Access forms like windows, I would have to use VB to 'diagram' the form, by looping through it's controls. Figured out how to do it, just never got around to developing that, because it had already sucked up a lot of my time. So, if you don't have forms to ask for report criteria, WolfWeb would probably do the trick for you. I'd be willing to sell ya the source for it for $50 and a couple of beers the next time your in Dallas! Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Christopher Hawkins Sent: Friday, March 19, 2004 11:03 AM To: accessd at databaseadvisors.com Subject: [AccessD] Using Access for Reports w/an ASP app? Greetings! Here's my deal - I have a spectacularly cheap client who brought me on to fix an Access application that was botched by another programmer (90% of my business falls into this category. :P), but they've decided that Access is at least partly to blame for the failure of the project (again, I say :P). So they want me to re-write the front-end in ASP. No problem there - most of the problems are in the UI; the schema is surprisingly good, considering the UI (it's truly poor). The roadblock I'm encountering is this: how do I make sure they can still access their reports? They have some pretty complex reports in that Access app, and they won't pay for Crystal. I was thinking that I'd leave a copy of their Access mdb on the web server and then write a dll that would open a report, write it ti pdf, and then return it to the browser. The only problem is...I have no idea how to do that. I also don't know if it's a smart thing to do. I also don't knwo if they'll want to pay for the dev time. Barring the above idea, is anyone aware of a cheap or free web reporting utility/tool/component that I can use to either leverage their existing reports, or re-create them for web use without having to go with something expensive like Crystal? -Christopher- -- _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com