Visual Basic with Crystal Reports Error

[campbere]

I am using VB 6, Oracle 8, and Crystal Reports 6. I have come across a strange error in my program and have narrowed it down to the reason.

I have a Visual Basic Application that uses Crystal Reports to produce about 30 reports. However I noticed that 2 or 3 of them reported all zeros for a 2 columns out of many columns on end users machine. I ran the reports on my machine and the columns had numbers. The difference between my machine and the end users is that I have Crystal Reports installed. Once I installed CR on an end user's machine the reports that had zeros now actually have the correct values. I don't have enough licenses to distribute CR to every machine, so that is not an option. Is there a way to correct this problem? Is there a certain DLL I am missing?

Does anyone have any ideas or seen something similiar?

 

[kenhamady]

Are these columns formulas?
Do they use functions? Ken Hamady

http://www.kenhamady.com/

Crystal Reports Training/Consulting and a
Quick Reference Guide to VB/Crystal (including ADO)

 

[campbere]

The columns are not funcions or formulas. I have noticed one other pattern that I am in the process of verifying. I noticed that both columns are number types from the Oracle table.

This is still a strange problem. I am going to check the other reports to see if any other number fields are used.

So far I havent found anything in Seagates knowledge base either.

 

[campbere]

I have confirmed that it is only number fields that are having this problem.

 

[kenhamady]

Fields directly from a table or a View/SP?
Same ODBC Drivers on both PCs?
Are these fields from a different table than the others?
Ken Hamady

http://www.kenhamady.com/

Crystal Reports Training/Consulting and a
Quick Reference Guide to VB/Crystal (including ADO)

 

[campbere]

They are from a table. The fields all come from the same table. As far as ODBC drivers I will have to try that today.

 

[campbere]

Ken,

I finally found a way to make this work. I eliminated the possibility of ODBC differences, I made sure everyone had the same one. After that I just happened to write a query with a number column and used it in the report. It worked and it works on others computers as well. Very strange that to get the problem solved I had to base the report off of a qury.

Oh well.