Report generators 1

[petermeachem]

My customer is using a vb6 + crystal programme with a sql7 database under Citrix. Every so often the terminal server blue screens when printing. They would like crystal replaced with some thing else. ( I reckon the problem is caused by the printer drivers but they can't find anything that doesn't crash and prints properly ).
Has anyone any experience of alternative report writers? The reports are mostly text with a few dividing lines here and there, but some are quite large running to a hundred pages or so. I have vs reports, which is extremely poor and very slow.

http://www.therockalltimes.co.uk

http://www.robotwisdom.com/

 

[tedsmith]

Have you tried printing the same report that crashes to a different printer on another computer or direct from the computer that has the app running?
This would prove if it is your app or the printers

 

[petermeachem]

They aren't even sure what crashes it, except that it does seem to coincide with printing (which takes place at about 3am!). Word etc never appear to crash the machine, so they want to try a different report writer to see if it is crystal. Crystal is also a vile thing to install and I would like to get away from it.

http://www.therockalltimes.co.uk

http://www.robotwisdom.com/

 

[tedsmith]

You can have crystal reports as a component inside a VB app. It automatically installs with the VB.
There shouldnt be a problem with this any more than any other program.
Maybe you have some lines or things on the reports that are pushed outside the margins by combinations of inappropriately dimensioned, unusual or faulty data like $123.00000001 when you should have formatted the field to currency or something like that?
This will stop an unattended print run and they are assuming the computer has crashed?

 

[MichaelRed]

look in the Ms. A. fora, I have posted a brief routine to generate a basic report in Ms. A. from a record source. It is quite crude, but easily useable in concept for the standard 'ledger' report. It is certainly NOT what you would choose as a final report on a professional basis, but it might illustrate the ease of use of the Ms. A. reporting tool. There are a ferw threads in VB which reference the use of Ms. A. as a reporting tool for VB database apps. So, AN approach could be cobbled together which extracted the SQL data for a report to an Ms. A. database / recordset, run the report generator thinnggyy (or some variation thereof) and print the Ms. A. reports all from within VB. In this, you could QUICKLY create some basic (but perhaps not very attractive) reports. From having the basic reports, you could pretty well 'pretty them up' in Ms. A. and thereafter just skip the autogeneration of hte ugly versions. With ms. A. 2K and later, Accessing the SQL server db directly through ADO is also quite simpllistic, so when the reports are of 'acceptable' quality, you can just run the Ms. A. Reports directly from VB. No third party report greneration 'stttuuuuuuufffffffff' to contend with. Reasonable capability of generating new reports based on the actual recordset.


hmmmmmmmmmmmmmmmm ... mmmmmmmm

Why didn't I think of this approach way back when I actually HAD a job?




MichaelRed
m.red@att.net

Searching for employment in all the wrong places

 

[petermeachem]

Nice idea, except that in this case the report is based on tempdb tables which I don't think would be easily accessible from Access.

http://www.therockalltimes.co.uk

http://www.robotwisdom.com/

 

[MichaelRed]

with the plethora of recordset options available via either VB or Ms. A. it -pratically speaking- is just a matter of wheather the product (result) is worth the price (effort). Surely, if you are re-designing the reporting process, a detour through the recordset generation is not even close to a "show stopper".

But enough of the soap-=box derby. I've offered the suggestion, it is (way) out of my hands what happens.





MichaelRed
m.red@att.net

Searching for employment in all the wrong places