nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Nachgestelltes ".0" wird beim Veröffentlichen im Portal an das Ende der Zeichenkette angehängt

BrittanyBurson

Hallo @BruceHarold und alle,

Wahrscheinlich etwas ganz Offensichtliches (Entschuldigung!), aber ich stelle fest, dass beim Veröffentlichen in Portal 10.8.1 mit Data Interoperability ein Zeichenkettenfeld nur mit Zahlen während des Veröffentlichungsprozesses jeweils eine .0 am Ende jedes Wertes angehängt bekommt. Ich habe bereits in den FME-Foren gesucht, aber bisher keinen Erfolg gehabt.

Vorschau aus dem Workbench-Schritt kurz bevor die Daten veröffentlicht werden:

Das Ergebnis im Portal:

Gedanken oder Vorschläge?

Vielen Dank wie immer!

Finde mehr Beiträge mit dem Tag

Accepted answers

BrittanyBurson

Update in case anybody else encounters this:

Many thanks to @BruceHarold who suggested the AttributeRounder, which worked despite the values not actually having decimal places in the data. The original cause I assume to be user error, as I configured a scaled down version of the workflow and did not encounter the issue again.

All comments

BrittanyBurson

Update in case anybody else encounters this:

Snow-King

I also have some issues with the trailing .0 in string data for 2 or 3 days now. Every number gets a .0 added after the insert from FME. In my case, I don't use the suggested Transformer. Until this monday everything worked fine.

@BrittanyBursonwas BruceHarolds suggestion via private message becaue there is no comment. Did you change your workbench or datatype designation to solve the issue?

BrittanyBurson

Hi @Snowking

Yes, I emailed @BruceHarold and landed on the suggestion. I never saw the .0 introduced in any of the cache previews, but it would appear there at the end.

I eventually test rebuilt the workflow and published a new layer, setting the field manually to string when writing and the issue did not reoccur. So I just figured it was user error as I am pretty new to FME/Data Interop. I kept the AttributeRounder to not have to rebuild my entire workflow at the time. However now that you've written this it's possible it would have been reintroduced at some point in my test rebuilt workflow or is a bug.

Sorry I am not of much help. Bruce is fairly active here so he may have more to add!

bharold

Hi, please make sure the feature service you are writing to doesn't define the target field as double. Data Interop will happily write numeric strings into a double. Are you creating the service with the writer or does it already exist? We would like to reproduce the problem here so the workflow is important.

Snow-King

Hello @BrittanyBurson, hello @BruceHarold , thanks for your responses!

The feature service target field is defined as a string(20) in both: FME writer and hosted feature service.

The layer was initialised by uploading a FileGeodatabase into AGOL. After upload the data is daily updated by FME workflow.

It exists as a hosted feature layer since 26th Jan 2021. The problem occurred at the beginning of this week for the first time. Nothing changed during our FME workflow since 3rd December.

Unfortunately I can not delete the existing layer because of Covid-19 related contents. Maybe I'll create a second feature layer with the exact same data and datatypes, testing my updating workbench/workflow and replace the the datasources in the linked apps and maps via AGOL assistant.

It's frustrating that something in FME or AGOL changes string data. A taling zero looks kind of weird for active Covid cases ...

fme_writer.PNG

feature_layer.PNG

bharold

Thanks for the workflow thumbnail, we'll chase it here, in the meantime please use an AttributeRounder.

Snow-King

Your welcome, thanks for yor advise and help!

AttributeRounder changed nothing. Of course adding a space behind the value changed it and the the numbers appear without tailing zero. That's a neat little workarround, but I will recreate the feature layer today and test this new layer with the AttributeRounder, too.

bharold

Hi, we attempted to reproduce your issue but could not, we recommend opening a support call so the analyst can see your data and ETL tool - thanks.

Nimm an der Diskussion teil

Angemeldete Mitglieder können Beiträge verfassen, Updates folgen und mehr. Neu hier? Registriere ein kostenloses Konto.

Schnellzugriffe

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.