Informatica Tips 

Informatica General Notes 

What is lookup transformation in informatica ?

HOW TO Use a Joiner transformation instead of Lookup Transformation

HOW TO De-normalize data/pivot rows into columns

How can I manage multiple rows to a single row - multiple column?



Join these two tables over descriptionID
then use an Aggregator
group by product ID
first outputport productid
then create 3 outputPorts
englishdesc with
max(iif(cultureid='en',description,' '))
arabicdesc with
max(iif(cultureid='ar',description,' '))
frenchdesc with
max(iif(cultureid='fr',description,' '))

I am trying to run a SQL Select statement which looks like this:

"SELECT * FROM TableName WHERE FieldName = '" + Request.QueryString("ProNumber") + "'"

But, I am getting a End of statement expected error. The value passed in contains a single quote. Is it a problem?


When the SQL statement is assembled via string concatenation, the appearance of a single quote inside the QueryString value will break the statement. For example, when built, the statement will look like this:

SELECT * FROM TableName WHERE FieldName = 'QueryString's Value'

This is broken as the value closing delimiter appears twice; that is, there are an odd number of single quotemarks.


Building an SQL statement by concatenating strings is not advisable. It is:

·unscalable -- The database will "hard parse" for every execution of the SQL -- for many systems parsing is slower than actual query execution. (Not unique to concatenating strings, but is true of any raw SQL query.)

·prone to failure for every last name input like O'Connor (or similar surname), possessive, or contracted input.

·vulnerable to SQL injection by the user if input parameter values are used as-is.

The dangers of SQL injection are humorously illustrated by Randall Munroe (although his specific example applies only to SQL Server and PostgreSQL).

A good, easy, scalable and safe approach is to use parameterized queries. The parameters for such queries are called bind variables. Developers often refer to parameterized queries or to bind variables, but they are closely related terms for the same concept.

In Java a parameterized query can be called using a Prepared Statement. An example of a parameterized PreparedStatement follows:

PreparedStatement ps = con.prepareStatement ("SELECT * FROM TableName WHERE FieldName = ? ");

Using parameterized queries is preferred because of scalability and built-in checks for sterile inputs.

A weaker alternative is do-it-yourself "sanitization of inputs," that is, escaping single quote characters. Caution: default escape characters vary by DBMS and can be overridden. For most DBMS, doubling the single-quote character is the default means of escaping a single-quote; but, for example, mySQL uses a backslash as the escape character. Assuming you never want to use mySQL, you could:

"SELECT * FROM TableName WHERE FieldName = '" + replace(Request.QueryString("ProNumber"), "'", "''") + "'"

This fix will produce the following statement:

"SELECT * FROM TableName WHERE FieldName = 'QueryString''s Value'"

Which is syntactically correct. Following Randall Monroe's example, suppose a disgruntled former employee inputs this anonymously on your public-facing website:

Robert'; DROP TABLE student;

The resulting SQL ends up being this harmless statement, and security problems are avoided (although scalability issues remain):

"SELECT * FROM TableName WHERE FieldName = 'somevalue''; DROP TABLE student;'"

In reality, a knowledgable hacker would use a function call rather than DDL, but the concept is similar.

The two types of unit testing are:

1.Quantitative testing

2.Qualitative testing