Question

User parameter including backslash is converted to forward slash or reveals GUI TEXT

ferdinandbogman

Dear readers,

 

A strange thing occurs today. In an an AttributeManager, I changed the value of an output attribute, from a fixed string to using a user parameter, partly.

The original string was:

 

mkdir "Y:\\Basis\\Kunstwerken\\@Value(KWK)\\@Value(KW_CODE)"

 

I substituted the part in bold with a user parameter (in bold, too):

 

mkdir "$(Kunstwerkmappen)\\@Value(KWK)\\@Value(KW_CODE)"

 

Now, here's the funny thing. If I provide the user parameter with the original string, the result is (one record as an example):

copy "I:\\BEHEER\\Temp\\Ferdinand\\LM_fotos\\Pictures_LM249DrempelsZestienhoven\\061720122651.jpg" "Y:\\Basis\\Kunstwerken\\Gemalen\\KGM-231\\061720122651.jpg"

 

All seems fine. But the idea is to be able to change the value of the user parameter. So I tried filling in "I:\\BEHEER\\Temp\\Ferdinand\\LM_fotos\\Kunstwerken" (without the quotes)

I get this result:

 

copy "I:\\BEHEER\\Temp\\Ferdinand\\LM_fotos\\Pictures_LM249DrempelsZestienhoven\\061720122651.jpg" "I:\\BEHEER\\Temp\\Ferdinand\\LM_fotos/Kunstwerken\\Gemalen\\KGM-231\\061720122651.jpg"

 

Notice the backslash in the part "LM_fotos\\Kunstwerken" has changed to "LM_fotos/Kunstwerken"?

 

It reminds one of string replacement or escape characters. But in both strings, the combination that would matter is the same: s\\K. Changing the name of the directory Kunstwerken to something els doesn't make a difference. And none of the other backslashes are converted either.

 

So why does this not work the way I expected?

 

Kind regards,

Ferdinand.

 

PS: I am unable to reproduce this, but at some point it got worse or, rather, weirder. I got the GUI TEXT content back as part of the result, somewhat like what was reported here to happen in an underlying Python script.

Don't know if that helps pointing in the right direction.

 

 

8 replies

ferdinandbogman

In addition to this, today I find that a reference to a file geodatabase in a reader has been "corrupted" the same way:

 

Unable to connect to the File Geodatabase at 'I:\\BEHEER\\Temp\\Ferdinand\\FME_Taskforce\\Geheugengebruik\\64-bits/WSV_Geometrie.gdb'

 

This line I copied from the log for a run where I removed everything from the parameter that point to the file geodatabase, except for the geodatabase itself. It is in the same directory as the FME model. In a text editor I saw that the reference was actually:

 

#!  DATASET="$(FME_MF_DIR)WSV_Geometrie.gdb"

 

So I concluded that I could leave out the path. Now it seems the error is in the FME-variable containing the forward slash, or somehow being added.

What could be the cause of this?

 

 

chrisatsafe
Rank
Badge +2

Hi @ferdinandbogman​ ,

 

Sounds like something isn't quite right here. By any chance are you able to send in your workspace(s) and the log file so our team can take a closer look into this? https://community.safe.com/s/submit-case (if you do, please feel free to either reference this question or the issue number: FMEENGINE-48741)

 

From what it looks like, the issue mentioned in the linked question has not yet been addressed so I have linked your question to ensure this post is updated in case there is a status change.

 

What build of FME are you using when you observe this behaviour (Help > About FME Workbench).

ferdinandbogman

Thanks @chrisatsafe​, for replying.

 

The zipfile attached contains two versions of the workspace, one with the fault (_a), the other without it. Logs are included, which show the difference in results.

They were both run today in FME 64-bit 2019-2.3.2 (build 19825).

 

Perhaps you can draw some conclusion about the cause.

 

Kind regards,

 

Ferdinand.

1 Attachment
ferdinandbogman

Sorry @chrisatsafe​ ,

 

I overlooked the suggestion to submit a case.

 

See case C657413 for

 

The file included with the case is the same as the one included here.

 

We're using FME Desktop 2019.2.3.2 (20200320 - Build 19825 WIN64)

 

And, importantly, the problem still exists.

 

Kind regards,

 

Ferdinand.

ferdinandbogman

@chrisatsafe​ ​,

I'm not sure if I should put this here, or add it to the case. Anyway, I let a colleague, for whom I built this workbench in the first place, test the thing. I hoped the error would be some location-specific issue and he would test in in a different one. He got the same issue.

 

That is, he was able to reproduce the variant which I described in the PS of my original question. One of the lines that is output reads:

 

mkdir "I:\\BEHEER\\Werkprocessen\\Landmeten\\Projecten lopend\\LM250_KW WS ObjectMeldingen\\7_foto/test GUI TEXT Kunstwerkmappen Geef de locatie van de kunstwerkmappen:\\Duikers\\KDU-8863"

 

Here we see the forward slash again. But also the text in bold, which is added in between the text that should be output. The text consists of:

  • a parameter (GUI TEXT)
  • the text that appears in the GUI when the workbench is run
  • the text that was filled in by my colleague

It might help to say that, while we see a path, this is actually defined as a text parameter, since it needs to be added to a string.

 

Hope this helps,

 

Ferdinand.

jwarren
Rank
Badge +4

I'm having a very similar issue. I have the following SQL in the "SQL To Run After Write" on a featureWriter, writing to SQL Server table:

 

insert into event.import.dataload (KEYCOL, recordType) VALUES ('U:\\Systems\\POLER\\Data Migration Plans\\Migration FME Workspaces\\ORI_Level1_ETL_config\\01ETL_ORI_validationEvents.json', 'M')

 

The value in the table is:

U:\\Systems\\POLER\\Data Migration Plans\\Migration FME Workspaces/ORI_Level1_ETL_config\\01ETL_ORI_validationEvents.json

which has one backslash converted to a forward slash...

jwarren
Rank
Badge +4

I'm having a very similar issue. I have the following SQL in the "SQL To Run After Write" on a featureWriter, writing to SQL Server table:

 

insert into event.import.dataload (KEYCOL, recordType) VALUES ('U:\\Systems\\POLER\\Data Migration Plans\\Migration FME Workspaces\\ORI_Level1_ETL_config\\01ETL_ORI_validationEvents.json', 'M')

 

The value in the table is:

U:\\Systems\\POLER\\Data Migration Plans\\Migration FME Workspaces/ORI_Level1_ETL_config\\01ETL_ORI_validationEvents.json

which has one backslash converted to a forward slash...

I just tried exactly the same SQL writing to the same table using an identical transformer and it wrote the backslash correctly

P

This was causing me grief too. I was trying to pass a folder containing a file geodatabase parent path as a parameter to arcpy using a system caller.

 

Its all down to FME automatically replacing the beginning of paths within a workspace which match the workspaces's folder with $(FME_MF_DIR).

Documented here: https://community.safe.com/s/article/fme-mf-dir-environment-variable

 

Unfortunately the FME parameter adds a trailing forward slash onto the end of the $(FME_MF_DIR) parameter, even on windows.

 

My user Parameter containing desired Path for Geodatabase folder 

$(TemporaryGeoDatabaseLocation) = D:\\BatchProcesses\\ServiceArea\\TemporaryData

 

My FME workspace was in D:\\BatchProcesses\\ServiceArea\\

 

So $(FME_MF_DIR) = D:\\BatchProcesses\\ServiceArea/

Causing the parameter to be rewritten as: $(FME_MF_DIR)TemporaryData

 

But get evaluated as D:\\BatchProcesses\\ServiceArea/TemporaryData 

 

This was not compatible with arcpy when passed via a system caller in my use case.

 

After much digging about here is my workaround:

 

Option 1: This is a poor solution as it is hardcoded in every instance. Use the FME_MF_DIR parameter and TrimRight command to strip the trailing backslash on the workspace folder and hardcode "\\TemporaryData" into any use of the folder.

 

@TrimRight($(FME_MF_DIR),"//")\\TemporaryData

 

 

Option 2: Wrap any use of your original parameter with a string replacer to change any forwardslashes back to a backslash.

 

@ReplaceString($(TemporaryGeoDatabaseLocation),"/",\\,caseSensitive=TRUE)

 

Note: the backslash is an escape character and must not be included in double quotes as it will escape the ending quote and cause an error.

 

Reply


Community Stats

28,723
Posts
109,510
Replies
36,559
Members
Terms & ConditionsCookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.