Apply IS_IGNORE_PAGINATION when export to CSV in JasperReports

Problem

I'm writing a report which needs to be exported to pdf and CSVformat.
when output format is CSV, it should be ignore pagination. 
The screenshot as bellowing is wrong, it has pagination in CSVfile:

Solution
JasperReports provides IS_IGNORE_PAGINATION.
It is a fill-time parameter, therefore you'll have to set it when filling the report:

params.put(JRParameter.IS_IGNORE_PAGINATION, Boolean.TRUE);
JasperFillManager.fillReport(jasperReport, params, dataSource);


See...CSV file does not have pagination after set IS_IGNORE_PAGINATION to TRUE.

20 Database Design Best Practices

1. Use well defined and consistent names for tables and columns (e.g. School, StudentCourse, CourseID ...).
2. Use singular for table names (i.e. use StudentCourse instead of StudentCourses). Table represents a collection of entities, there is no need for plural names.
3. Don’t use spaces for table names. Otherwise you will have to use ‘{‘, ‘[‘, ‘“’ etc. characters to define tables (i.e. for accesing table Student Course you'll write “Student Course”. StudentCourse is much better).
4. Don’t use unnecessary prefixes or suffixes for table names (i.e. use School instead of TblSchool, SchoolTable etc.).
5. Keep passwords as encrypted for security. Decrypt them in application when required.
6. Use integer id fields for all tables. If id is not required for the time being, it may be required in the future (for association tables, indexing ...).
7. Choose columns with the integer data type (or its variants) for indexing. varchar column indexing will cause performance problems.
8. Use bit fields for boolean values. Using integer or varchar is unnecessarily storage consuming. Also start those column names with “Is”.
9. Provide authentication for database access. Don’t give admin role to each user.
10. Avoid “select *” queries until it is really needed. Use "select [required_columns_list]" for better performance.
11. Use an ORM (object relational mapping) framework (i.e. hibernate, iBatis ...) if application code is big enough. Performance issues of ORM frameworks can be handled by detailed configuration parameters.
12. Partition big and unused/rarely used tables/table parts to different physical storages for better query performance.
13. For big, sensitive and mission critic database systems, use disaster recovery and security services like failover clustering, auto backups, replication etc.
14. Use constraints (foreign key, check, not null ...) for data integrity. Don’t give whole control to application code.
15. Lack of database documentation is evil. Document your database design with ER schemas and instructions. Also write comment lines for your triggers, stored procedures and other scripts.
16. Use indexes for frequently used queries on big tables. Analyser tools can be used to determine where indexes will be defined. For queries retrieving a range of rows, clustered indexes are usually better. For point queries, non-clustered indexes are usually better.
17. Database server and the web server must be placed in different machines. This will provide more security (attackers can’t access data directly) and server CPU and memory performance will be better because of reduced request number and process usage.
18. Image and blob data columns must not be defined in frequently queried tables because of performance issues. These data must be placed in separate tables and their pointer can be used in queried tables.
19. Normalization must be used as required, to optimize the performance. Under-normalization will cause excessive repetition of data, over-normalization will cause excessive joins across too many tables. Both of them will get worse performance.
20. Spend time for database modeling and design as much as required. Otherwise saved(!) design time will cause (saved(!) design time) * 10/100/1000 maintenance and re-design time.

Read more: http://www.javacodegeeks.com/2012/02/20-database-design-best-practices.html#ixzz1lZ2GPfDI

50 Most Frequently Used UNIX / Linux Commands (With Examples)

http://www.thegeekstuff.com/2010/11/50-linux-commands/

1. tar command 

2. grep command 

3. find command 

4. ssh command 

5. sed command

6. awk command 

7. vim command 

8. diff command 

9. sort command

10. export command

11. xargs command

12. ls command 

13. pwd command

14. cd command

15. gzip command 

16. bzip2 command 

17. unzip command

18. shutdown command

19. ftp command

20. crontab command

21. service command 

22. ps command

23. free command

24. top command

25. df command

26. kill command

27. rm command

28. cp command

29. mv command

30. cat command

31. mount command

32. chmod command

33. chown command 

34. passwd command

35. mkdir command

36. ifconfig command

37. uname command 

38. whereis command 

39. whatis command

40. locate command

41. man command

42. tail command

43. less command

44. su command 

45. mysql command

46. yum command

47. rpm command

48. ping command 

49. date command

50. wget command 

ORA-12704: character set mismatch

Problem
As I execute this SQLstatement

1:  SELECT .....(ignore)  
2:      CASE   
3:        WHEN NIGT001.TAX_CD='15'  
4:          THEN (SELECT NIGT007.ADTR_NM  
5:             FROM NIGT007   
6:             WHERE NIGT001.PRST_ADTR_CD = NIGT007.ADTR_STAFF_CD(+) )  
7:       ELSE ''  
8:      END AS ADTR_NM  
9:  FROM NIGT001,NIGT013,NIGT007, ......(ignore)     
10:  WHERE ......(ignore)  
11:  ORDER BY .....(ignore)  

It showed this error message

ORA-12704: 字元設定不符合
12704. 00000 -  "character set mismatch"
*Cause:    One of the following
           - The string operands(other than an nlsparams argument) to an
           operator or built-in function do not have the same character
           set.
           - An nlsparams operand is not in the database character set.
           - String data with character set other than the database character
           set is passed to a built-in function not expecting it.
           - The second argument to CHR() or CSCONVERT() is not CHAR_CS or
           NCHAR_CS.
           - A string expression in the VALUES clause of an INSERT statement,
           or the SET clause of an UPDATE statement, does not have the
           same character set as the column into which the value would
           be inserted.
           - A value provided in a DEFAULT clause when creating a table does
           not have the same character set as declared for the column.
           - An argument to a PL/SQL function does not conform to the
           character set requirements of the corresponding parameter.
*Action:
第 97 行, 資料欄: 133 發生錯誤

Root Cause
The problem result from NIGT007.ADTR_NM is NVARCHAR2. 
But the case-when-else statement return empty string in else statement. The empty string is VARCHAR2. 
That's why it complains "character set mismatch". What we need to do is do casting.

1:  SELECT .....(ignore)  
2:      CASE   
3:        WHEN NIGT001.TAX_CD='15'  
4:          THEN (SELECT NIGT007.ADTR_NM  
5:             FROM NIGT007   
6:             WHERE NIGT001.PRST_ADTR_CD = NIGT007.ADTR_STAFF_CD(+) )  
7:       ELSE CAST('' as NVARCHAR2(10))  --do cast here
8:      END AS ADTR_NM  
9:  FROM NIGT001,NIGT013,NIGT007,, ......(ignore)    
10:  WHERE ......(ignore)  
11:  ORDER BY .....(ignore)