Bug when editing tasks containing transforms

[nahowe]

Is there a known bug, issue, or workaround for tasks containing a transform? Every time I create new columns via a transform and run some tests I cannot go back and get my edits to save on the task/transform. I have tried stopping, saving, stop/save together, etc, and it will even let me make changes, but when I click save and go back to review my changes (before starting the task again) the changes never take. I caught this when I pressed save and ran a task that ended up not doing what was expected, so it doesn't seem just running the task after saving fixes anything either.

Thanks

[Heinvandenheuvel]

>> Is there a known bug, issue, or workaround for tasks containing a transform? 

No. Just No. That would be 'too big a bug'. All customers would be yelling.

Is your user permission "designer" or admin? I'm sure that would give a clear 'not permitted' error, but just check.

Did you ever get this screen??

>> I can't confirm if it ever did this before as we have just started working with transforms. 

And there you have it. You "just started working", so it is much more likely that either you are simply doing something wrong perhaps incorrectly interpreting a 'save' / 'cancel' situation than there being a bug. For example if you did not see the '[OK]' button at the bottom of the new column screen but just used 'x' - out on the top right then you may 'see' the new column name but it does not exist until you use OK and then Replicate will make sure it is saved or cancelled. 

Did you ever see the little star in the task tab?

Can you make other changes? Try something simple like "full load tuning" - "Commit rate during full load:" and change that to '12345'. Save, close browser window, re-open and check value.

Maybe, just maybe, the replicate server runtime environment has changed (new username) and the new environment does not have the right to write to previously created file in the data\tasks folder? It is unlikly to start up in that case as the data\logs folder typically would have the same protection but just maybe.

@SushilKumar "Observed the same behavior with some other customers as well."

Please be specifc. Use version number like "(2023.5.0.152)", not internal stuff like "Mat 2024 GA". And use exact circumstances please because if this happens to everyone than surely the GA version would not have passed QA.   

[nahowe]

Can somebody confirm the version we are on, 2024.5.0.144 = May 2024 SP3??

[john_wang]

Hello @nahowe ,

Not really. 2024.5.0.144 is the GA release of 2024.5.

SP3 is not official release yet, so the build number is unknown. The current officila release builds are:

2024.5 GA	2024.5.0.144
2024.5 SP1	2024.5.0.247
2024.5 SP2	2024.5.0.316

Regards,

John.

[nahowe]

1. I am designer and haven't had any problems editing tasks or anything yet. Yes I have seen that screen, but again have tried many methods including stopping the job first, editing the job first, etc and I always save.

2. That is quite the assumption. We have used this product in Dev since last year. It is pretty obvious if a job is saving or not. Creating tasks and adding filters all work the same as creating transforms. An asterisk is a universal indicator something isn't saved and therefore hasn't been missed in our process. We may be doing something wrong, but it would need to be something more technical than your suggestion.

3. I am able to make other changes including that one to full load tuning, yes. Same with filters. Only thing not working is transform.

4. Nothing is changing on our end. This could be where the mix up is happening if Qlik itself doesn't like changes to a transform. I don't see how that would affect usernames, environments, or any other data. 

5. 2024.5.0.144 is the version we are on

[nahowe]

So another clarification - This is only for one table and for the one table transformation. We tried doing multiple tables and using global transformations instead and this seems to be working (allowing edits). It will be our workaround, but there is definitely a bug on the table by table transformations.

[Heinvandenheuvel]

>> 1. I am designer and haven't had any problems editing tasks or anything yet.

Great. Now we know.

>> 2. That is quite the assumption. We have used this product in Dev since last year. It is pretty obvious if a job is saving or not.

Great. Now we know.

>> 3. I am able to make other changes including that one to full load tuning,

Great. Good starting point.

>> 4. Nothing is changing on our end.

Great, now we know.

>> 5. 2024.5.0.144 is the version we are on

Great. Now we know and we also know from the handy table by @john_wang  that there are more recent versions available so you should really try (in DEV) whether this fixes the issue if it were to be a known bug. This should probably be your first step as it is a win-win. Even if it doesn't fix the issue, when you escalate the problem the first thing support will suggest is to upgrade. so you might as well get that done.

>> This could be where the mix up is happening if Qlik itself doesn't like changes to a transform. I don't see how that would affect usernames, environments, or any other data. 

Correct. That's hard to imagine. IN my years in supporting the product I have seen example where customer moved a data directory, or changed the username for repctl where there was enough room to execute but not enough to change.

So now let's focus more on the issue. In you clarification you already added "  This is only for one table and for the one table transformation. ".   So other for other tables you can add, and change transformations if I interpret that correctly.  That would  make sense because as per my first remark for replicate to just not be able to add transformations in general is ludicrous.

- Does this one table already have some transformations? 

- If you create a similar table with just a hand full of columns can you successfully add the transformation you intended to add to the main table but where it failed to save?

- Are there perhaps too many transformations hitting some internal limit without an explicit message.

- Is the transformation to be added exceedingly complex / big? Can you please share the transformation to be added? If you feel the need obfuscate column names/data values keeping the string length the same.

- Is there anything special about the table, like many hundreds or thousands of columns?

- Is this a column being added, or is there an existing transformation to be modified?

- Can you provide the existing transformation output for the table from the json as a text attachment, or the even the whole task but telling us which table/column?

Good luck,

Hein

[DesmondWOO]

Hi @nahowe ,

I could not reproduce your problem on Qlik Replicate v2024.5.0.316. Here are the steps:

1. Add a new column "ts1" with the expression datetime('now')
2. Save and start the task.
3. Check target table, column "ts1" is there.
4. Stop task.
5. Add a new column "ts2" with the expression datetime('now')
6. Reload task
7. Check target table, column "ts2" is there.

Could you provide the steps to reproduce the issue, or share more information as Hein mentioned earlier?

Regards,
Desmond

[nahowe]

Hi @DesmondWOO,

This is good news as we are on v2024.5.0.144 and plan to upgrade to v2024.5.0.316 asap. For now; however, our steps are more like this:

1. Add a new column "ts1" with the expression datetime('now')

2. Save and start the task.

3. Check target table, column "ts1" is there.

4. Stop task.

5. Change the function on "ts1" from datetime('now') to date('now')

6. Save the changes

7. Checking before or after running the saved job will show the function still has datetime('now')

[mjbuckner]

Hello,

I am experiencing something very similar here.   I'm on Qlik Replicate version 2024.5.0.144.   From time to time, in our nonproduction environments we refresh the replicated data with a copy of our production database. Since we don't want all of the data from production in our test environment, we apply filters on 18 of the larger tables out of 211.  Before we reload the data, I edit the Date filters to bring over only data >= 2 weeks or 2 months or 6 months depending on the table.  We've done this for years going back to Attunity. 

Today, I edited the filters, and all proceeded as usual. Upon each edit of a filter, it did ask if I wanted to save it, as it always has, and I clicked Yes, then I Saved the task when I was done.  I happened to double check a value and found that it and all the others were set to the previous values.  I tried several times to edit and save and it wouldn't work.  I finally exported the task, edited it in a text editor and then imported it.  The values are now updated in the task.  

Has this been declared a bug and is there a known fix for it yet?

Thanks,

MJB

[DesmondWOO]

Hi @mjbuckner , 

I'm using v2024.5.0.316. I followed Nahowe's step but I could not reproduce the problem.

1) Add a new column with the expression datetime('now') 

2) Reload the task. Target table result:

3) Stop the task. Change "datetime" to "date".

4) Save task, and you will get a warning about "Some table transformation have been modified."

5) Check transformation again. It's still "date".

6) Reload the task.
7) The time portion becomes 00:00:00.

v2024.5.0.144 is a GA version. I recommend upgrading to v2024.5.0.316 sp2 and testing again, although I couldn't find a fix for this type of problem in the release note.

Regards,
Desmond