Michael Miller<\/A> attributeassistant<\/P><\/P>Ich habe Attribute Assistant so konfiguriert, dass eine ServiceID (Fremdschlüsselfeld) von einem sich schneidenden Service Pipe zu einem anderen sich schneidenden Service Pipe kopiert wird. Dies funktioniert korrekt beim Platzieren eines neuen Service Pipe-Features; jedoch erhalte ich inkonsistente Ergebnisse beim Aufteilen eines bestehenden Service Pipe-Features. Wenn das ServiceID-Feld einen Wert hat, der nicht mit einem Datensatz verknüpft ist, funktioniert es korrekt und kopiert die ServiceID auf das neue Service Pipe-Feature, das durch das Aufteilen erstellt wird. Wenn das ServiceID-Feld jedoch einen Wert hat, der mit einem Datensatz verknüpft ist, wird der Wert nicht kopiert.<\/P><\/P>Im AA-Code,<\/P>sourceFeature.get_Value(sourceField) gibt null zurück, wenn ein verknüpfter Datensatz vorhanden ist, gibt aber den ServiceID-Wert zurück, wenn ich eine ServiceID eingebe, die keinem Datensatz entspricht.<\/P><\/P>Ist dies ein Fehler oder kennt jemand eine Möglichkeit, dies zu umgehen?<\/P><\/P>Hier ist die genaue Konfiguration:<\/P>
<\/P>
Ich habe Attribute Assistant so konfiguriert, dass eine ServiceID (Fremdschlüsselfeld) von einem sich schneidenden Service Pipe zu einem anderen sich schneidenden Service Pipe kopiert wird. Dies funktioniert korrekt beim Platzieren eines neuen Service Pipe-Features; jedoch erhalte ich inkonsistente Ergebnisse beim Aufteilen eines bestehenden Service Pipe-Features. Wenn das ServiceID-Feld einen Wert hat, der nicht mit einem Datensatz verknüpft ist, funktioniert es korrekt und kopiert die ServiceID auf das neue Service Pipe-Feature, das durch das Aufteilen erstellt wird. Wenn das ServiceID-Feld jedoch einen Wert hat, der mit einem Datensatz verknüpft ist, wird der Wert nicht kopiert.<\/P>
Im AA-Code,<\/P>
sourceFeature.get_Value(sourceField) gibt null zurück, wenn ein verknüpfter Datensatz vorhanden ist, gibt aber den ServiceID-Wert zurück, wenn ich eine ServiceID eingebe, die keinem Datensatz entspricht.<\/P>
Ist dies ein Fehler oder kennt jemand eine Möglichkeit, dies zu umgehen?<\/P>
Hier ist die genaue Konfiguration:<\/P>
Let me try to explain the data model a little better:
There is a table called P_ServicesSummary. This table gets a uniqueid called ServiceID generated by Attribute Assistant. There is a 1:M relationship between P_ServicesSummary (Origin) ServiceID (PK) to the feature class P_Service(Destination) ServiceID (FK).
If the P_Service feature that I am splitting has a ServiceID value that matches a ServiceID in the P_ServicesSummary, it will return null as the value; however, if I enter "dumb data" into the ServiceID field like "12345", so there isn't a matching record in P_ServicesSummary table. The get value will return the "12345" and copy it to the newly created service feature correctly.
I will send the log information shortly.
OK, so I tested changing this value from "False" to "True" and it still doesn't work. The fields that do not have a relationship class with a link record work correctly, but the ServiceID field doesn't. For example, my InServiceDate and InServiceYear will copy to the newly created split feature, but the ServiceID does not.
I was thinking of something else, but I do not see that option. Could you activate the log file and maybe that can help us narrow it down. How are you splitting the service line? Does not make sense that get_value is not getting the value when split, unless the new feature is not getting is ID carried over because of the 1:M relationship. If you split a main that has a valid ID, with the AA turned off, do the resulting 2 features have the same ID, hence violating the 1:M relationship?
The key "OnCreateWhenSplit" has it's value set to "False". Should I change this to "True"?
There is an option to suspend the AA on split, can you check that in the loaded.aa.config file?
Angemeldete Mitglieder können Beiträge verfassen, Updates folgen und mehr. Neu hier? Registriere ein kostenloses Konto.
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.