Skip to main content

Houston,

We have a problem with the File Geodatabase writer that requires ArcGIS (not the API version). It performs differently in different virtual environments (Citrix) with different FME versions, on the same File Geodatabase. We suspect that the differences in the virtual environments are the cause of this, because the desired functionality is offered in all FME versions. We'd like to know which parts of the ArcGIS Desktop installation are used by FME, when writing to a File Geodatabase, in order to get to the bottom of the issue.

 

The details of the situation are as follows. As mentioned, we have two different virtual environments:

  1. A production environment with FME 2019 32-bits served in a "bubble". This is combined with ArcGIS Desktop 10.6.1, in a direct install (no bubble).
  2. A testing environment with FME 2019 64-bits and ArcGIS Desktop deployed the same way as the production environment

 

In the production environment, the File Geodatabase writer does not work* when the desired feature class (fc)does not exist and Table Handling is set to "Create if Needed". (This is what we'd like to achieve.)

Neither does it work* when the fc does exist and Table Handling is se to "Drop and create".

It only works when the fc exists and Table Handling is set to either "Truncate" or "Use existing".

 

In the testing environment, all works fine.

 

There is no reason to think that the 64-bit version should make the difference, since the functionality is offered in both. So we fear that deploying 64-bit FME in production will not solve the problem. Before we try that, we'd like to besure it does.

Rather we suspect that some permission is missing that allows for creation of new feature classes in a File Geodatabase, in the production enviroment. Or there could be a different cause altogether.

 

Where do we look?

Any suggestions are welcome.

(Mind you: I'm not asking for a workaround.)

 

Kind regards,

 

Ferdinand.

 

*What happens is FME.exe keeps running endlessly without progressing beyond the opening of the File Geodatabase for writing. Here's the last part of the log that is produced before I stop the workbench:

----

Creating writer for format: Esri Geodatabase (File Geodb)

Trying to find a DYNAMIC plugin for writer named `GEODATABASE_FILE'

FME API version of module 'GEODATABASE_FILE' matches current internal version (3.8 20190820)

FME Configuration: No destination coordinate system set

FME API version of module 'GEODATABASE_FILE' matches current internal version (3.8 20190820)

Writer `GEODATABASE_FILE_1' of type `GEODATABASE_FILE' using group definition keyword `GEODATABASE_FILE_1_DEF'

FME API version of module 'GEODATABASE_FILE' matches current internal version (3.8 20190820)

An ArcGIS license is already checked out. The product checked out is 'Standard'

Installed ArcGIS version is '10.6'

Connected to the File Geodatabase at 'LANDMETEN_OPLEVERING.gdb'

File Geodatabase release: '10.0'

Fast deletes enabled

The 'HAS_Z_VALUES' keyword is set to 'AUTO_DETECT'. With the exception of MultiPatch feature classes, the dimensionality of new feature classes will be based on the first feature written to the feature class. (Features with no geometry are considered 2D)

A default z-value of '0' will be used for all 3D features where z-values are not provided

Geodatabase Writer: Not simplifying geometries being written to the Geodatabase

----

Lots of viewers, no answers. Let me rephrase the question to make it a bit easier:

 

Which part of the ArcGIS Desktop installation is used by FME.exe when the File Geodatabase Writer tries to create a new table? Which executable, DLL or other?

 

See if that helps...


Lots of viewers, no answers. Let me rephrase the question to make it a bit easier:

 

Which part of the ArcGIS Desktop installation is used by FME.exe when the File Geodatabase Writer tries to create a new table? Which executable, DLL or other?

 

See if that helps...

Hi @ferdinandbogman​ ,

I am pretty certain if the TEST environment is working there is no reason the PROD environment wouldn't be working if the users of Citrix have the same access to ArcGIS Install when logged in. (check: can they run ArcGIS on these systems?)

FME makes use of the ArcObjects library - part of ArcGIS installation. I think this part is OK as it looks like it is getting that far, this proof is determined by FME checking out an ArcGIS license. So seems fine.

I'm assuming the same user has tested both environments?

Is the file geodatabase on a network share or a local drive?

Is this with all file geodatabase or a particular one?

Can you share the full log file?

Can you check windows event viewer for any indications of errors?

Could a user be permitted to log into the Citrix server via RDP and run the application to see if there is a dialog being presented to the user that is not shown via the Citrix application?

 

What's the history here? Did this work in the past?


Hi @ferdinandbogman​ ,

I am pretty certain if the TEST environment is working there is no reason the PROD environment wouldn't be working if the users of Citrix have the same access to ArcGIS Install when logged in. (check: can they run ArcGIS on these systems?)

FME makes use of the ArcObjects library - part of ArcGIS installation. I think this part is OK as it looks like it is getting that far, this proof is determined by FME checking out an ArcGIS license. So seems fine.

I'm assuming the same user has tested both environments?

Is the file geodatabase on a network share or a local drive?

Is this with all file geodatabase or a particular one?

Can you share the full log file?

Can you check windows event viewer for any indications of errors?

Could a user be permitted to log into the Citrix server via RDP and run the application to see if there is a dialog being presented to the user that is not shown via the Citrix application?

 

What's the history here? Did this work in the past?

Hello Steve,

 

Thanks for replying. I will see if I can get your research suggestions through to our system engineers. But now that it works, everybody seems to be happy except me. So I'm not sure if I can get them to put in any effort still. However, your suggestions may help debugging future issues as well.

 

It works? Well, in the meantime, we have moved on. Since yesterday the production environment is running on a new image, with some slight changes to the ArcGIS Desktop installation (patches, mostly). Me and another FME user have both FME 64-bit and 32-bit available in the production environment for testing purposes (this does not come via the image).

 

I now see that the 32-bit version does not write new tables to a FGdB, the 64-bit version does. That means we have narrowed down the problem to the way the FME-versions behave in the same environment.

 

I uploaded a set of files: the test workbench, the test File Geodatabase and logs for the 64-bit and the 32-bit runs.

 

Could you have a look at the logs? I don't see any difference in behaviour until the 32-bits version gets stuck.

 

In answer to your questions:

  • This was previously established by me in both environments.
  • The above logs are of production in the new situation. I also tried it from different network drives. We don't use local drives for data.
  • As you may see, I created a new FGdB for the test. So I assume it wasn't a particular FGdB that caused the problem.

 

Kind regards,

 

Ferdinand.

 

 

 

 

 


Hi @ferdinandbogman​, @steveatsafe​ 

What Esri software and bits version(s) are you using on the 32 and 64-bits platforms and how are they licensed?

By the way you'll have to use @person when answering.

 

Kind regards,

Krien Guijt


Hi @ferdinandbogman​, @steveatsafe​ 

What Esri software and bits version(s) are you using on the 32 and 64-bits platforms and how are they licensed?

By the way you'll have to use @person when answering.

 

Kind regards,

Krien Guijt

Thanks @krien​,

 

For the tip about addressing a specific person and for joining the conversation here. As I mentioned in my initial post, we have ArcGIS Desktop 10.6.1. which is 32-bit. I can add that we have 64-bit Background Processing installed along with it, and also ArcGIS Pro 2.4.2, which is 64-bit. This all applies to both environments.

But, as I mentioned in my reply to @steveatsafe​, the different FME behaviours can now be studied in one and the same Citrix-environment. So I assume that all variables are constant, except for the way both FME versions are deployed.


Reply