replace current access db reports/macros with vb interface

[psykoProgrammer]

Okay, another one for the gurus (you know who you are!).

We currently have an access db with forms for user interaction, and built in macros. The users use this to generate reports (also embedded within the access db). The trouble is, the developer is now gone, and the db is a mess (spaghetti code anyone?).

I made a VB6 application that connects to the db, and can extract data (easy enough so far). The trouble is that they want to continue to use these reports. I haven't figured out how i can call a report from vb. Whenever i attempt it, the report expects one of the embedded forms to be visible (i believe through the macro populating the report). This form hasn't been instantiated, and so the macro fails to pull any data, and the report stops short.

Can anyone tell me how i could work around this? Have i made sense with this request? I'm fairly new to this sort of interaction (i can pull and upate data, send data to word or something for reports, but can't figure out how to use the existing reports/macros).

Help...anyone...

Thanks!

 

[Sheco]

It might be easier to rewrite the reports in your native tongue.

 

[Sheco]

I mean write them using VB.

 

[psykoProgrammer]

Sorry, Sheco...i'm not sure i get what you mean :s

I want to use VB6, don't get me wrong, but i don't readily see how to easily create the same reports that already exist. In access it appears you simply drag 'n drop the items you want in order to determine the layout, and then query the data to populate the form (hence the macro). In VB6 i would have to (as far as i know) create a form, populate it, and hope it comes out looking half decent from the printer. Also, with many pages to print, i believe it would be faster/less cpu intensive to have the operation performed from directly within access. Is there any way to create the report in access, and then pull the data from VB, and send it back to access for the report itself?

As you can probably tell...i could use some help here :!

 

[Sheco]

Access is both a database an an application. You can get to the data with ADO but if you want to programmatically manipulate everything else then you can create an instance of the Access application object... just like you do when you want to use VB to manipulate Word and Excel.

That said, if you have the option, give strong consideration using Crystal Reports. It can be manipulated with VB and also the reports inside Access are just like stripped down versions of CR anyway.

If these reports don't need to be pretty, it should be very straightforward to write them into a text file. Then, if you need to display them, you can have a simple VB form with a big RTF textbox... just load the file into the box.

 

[MichaelRed]

From the other perspective, If you can do it in VB, then why not just straighten out the Ms. A. app you already have? Aomwthing like 90+% of the "Code" is Core VB, with just the object specifications being unique to Ms. A. Forms and reports are nearly interchangeable, while the "Macros" are readily transformed into Code (Procedures) which are VB. So ye olde drage & drope forms and reports are not significantly different than CR or VB Forms, the code is nigh unto and Macros easily transmorgified. The query builder completes the overall picture. Of course, sopme several (other) apps working together through OLE and assorted other interfaces offer a bit more power but only at hte cost of re-writting the app. While THAT may be a choice, I would suggest evewn more caution proceeding in that direction. After all MS has announced the demise of VB (at least in its' present guise) so re-writting anything worth re-writting in that venue is probably NOT a beacon of success.

Oh, well what's one more brick wall?





MichaelRed