IReport compiler doesn't give error with wrong sql

[janve]

Dear reader,

 

I have the following problem:

 

Description:

I use a sql query as a datasource for a report. The report runs fine. Then I rename a column in a table/ view in the database where the sql query and the report makes use of. After this I Compile the report and everything looks fine. However when you execute the report you will get an error message that says that there is a ‘Unknown column name’.

 

Questions:

1) Is there a possibility that when compiling the report (with ‘ANT’ or ‘Massive Compiler’) the compiler will do a “Read Fields†and checks in this way if the sql is still working?

2) Is there a way that if the sql is not working (anymore, because some change in the database) the compiler will give an error message?

 

Background of problem:

I started to have some problems with reports in my application. Having a check on the sql with "Read Fields" when compiling reports, prevents having reports in the application which doesn’t work because column names are not matching or the sql is not working.

 

I will appreciate much if there is an answer to questions 1) and 2)

 

Best regards,

Jan van Engelen

[svenn]

I don't know why you expect the tool to take care of this. Say I was to create a SQL string in Java. When you compile your code Java's not going to check your SQL. You going to find out there's a problem when you run it. Same thing happens with Jasper.

[janve]

Hi Sven,

 

Thanks for your reaction.

 

I will try to explain why I want to have the iReport compiler do this task for me…

 

I notice that iReport checks the sql when you start building a report. When creating a sql-string in iReport, iReport checks which columns are available for building the report. When you you want to use a field in the report which is not available by sql, and you compile, the compiler raises an error message “field not foundâ€. I like this feature of iReport, because it prevents me to make mistakes.

 

When compiling existing reports iReport doesn’t check anymore if the columns the reports want to use are really available. I can think of 3 reasons why it’s very convenient to have this check when compling with IReport:

1) It prevents me to make mistakes, some changes happens on the database and I'm not aware of all of them;

2) The error is discovered before the report is excecuted in production. I suppose that it’s good to discover errors In early stages, before to go to production;

3) To compile and check (by excecuting) all your reports manually is boring and can use some automation with Ant or Batchcompiler. It will be good if the compiler can do the check if the sql strings are still delivering the field which reports wants to use.

 

Best regards,

Jan van Engelen

[janve]

Hi Sven,

 

Thanks for your reaction.

 

I will try to explain why I want to have the iReport compiler do this task for me…

 

I notice that iReport checks the sql when you start building a report. When creating a sql-string in iReport, iReport checks which columns are available for building the report. When you you want to use a field in the report which is not available by sql, and you compile, the compiler raises an error message “field not foundâ€. I like this feature of iReport, because it prevents me to make mistakes.

 

When compiling existing reports iReport doesn’t check anymore if the columns the reports want to use are really available. I can think of 3 reasons why it’s very convenient to have this check when compling with IReport:

1) It prevents me to make mistakes, some changes happens on the database and I'm not aware of all of them;

2) The error is discovered before the report is excecuted in production. I suppose that it’s good to discover errors In early stages, before to go to production;

3) To compile and check (by excecuting) all your reports manually is boring and can use some automation with Ant or Batchcompiler. It will be good if the compiler can do the check if the sql strings are still delivering the field which reports wants to use.

 

Best regards,

Jan van Engelen