Filters in Table Loader transformation

[ErikLund_Jensen]

Hi @David_Billa 

The answers so far shows that a condition can be put into a table loader, but it is a bad idea, because it obscures what's going on and makes maintenance and troubleshooting a hell in the long run. I know from long experience...

When the job is opened, there is nothing on the canvas to tell that the loader has been tampered with down in the third subpane, so everybody would exepect it to be 1:1, The same with mapping and recoding. Don't drop variables or add expressions in the loader.

it takes less than a minute to insert an exctact (with output as a view) before the loader and do any subsetting and recoding there. Creating a view doesn't use any ressources, anyone opening the job can see that something is going on, and it is much easier to figure out what happens, because it is found in the where- and mapping-panes, not hidden in a subpane most people doesn't even know exists..

[Patrick]

@ErikLund_Jensen 

Just adding some opinion:

- Where clause in table loader: Whenever you do something "special" in a transformation add some comment so it does become visible on the job canvas.

- Using views for in-database processing means that you must be allowed to create such views in the database and you also need to drop the view after the load. That's another reason why I'd be using a SQL Insert transformation instead of the Table Loader.