Question

Parameters in Data Migration where clause?

  • 20 November 2020
  • 4 replies
  • 64 views

Badge +1

Hi!

Does anyone know if it’s possible to use any kind of input parameters in a Data Migration where clause?

 

In case you want to run the same job multiple times but using different input parameters without the need of edit the where clause statements every time..

\Mats


4 replies

Userlevel 3
Badge +6

Could you have the migration where clause point to a custom field(s) or some values in a custom logical unit, that way you can use the custom objects to drive the where clause input?

Badge +1

Thanks!

We have thought about using a CF, it’s a good proposal, but after some discussion we decided to try a solution using Data Migration conversion list instead… I think it should work...

Br

\Mats

Userlevel 6
Badge +12

Hi Mats,

 

One way to have input parameters is by setting the Change Defaults to ‘Allowed’ in the migration job

 

Below small example would explain it

Set the Change Defaults for column CUSTOMER_ID to Allowed

 

Add where condition

 

Start Job and then you can add additional conditions in the Default Where

 

Final result would the where condition added in the Mig Job as well as the where added in the execute job.

 

Hope you were looking for something similar.

 

Regards,

Damith

Userlevel 5
Badge +11

Never thought of using a custom field here. But It would mean to change the where clause basically in another field (or am I misreading the solution proposed by Technical Outlaws?).

Solution that DSJ is pointing out is great.

I had a situation where the clause would change based upon the input file. I made a utility api that reads the value of the source name end. It included special characters (I believe it where @ signs) around the variable to change every time. I would replace the @variable@, start the migration job and afterwards reset the @variable@ again so the migration job would be ready for the next run. It allowed me to have it run unattended.

For what ever its worth,

Steve

Reply