Skip to main content
Dear community,

 

 

I'm currently using FME 32bit on WIN64 with 16GB. To obtain better performance, I'm thinking on migrating to 64bit FME.

 

 

Can I exchange workspaces that were created on a 64bit FME with my colleagues who use 32bit FME? Is it right that the primary disadvantage of FME 64bit is the missing support for ESRI geodatabases compared to FME 32bit?

 

 

I read on an other topic that a parallel installation is possible. Are there any side effects by using 32 and 62 bit together on one machine?

 

 

Kind regards

 

Thomas
Thomas,

 

This is something I'm looking into at the moment having recently installed 64bit FME out of necessity. A process I was running was really struggling under 32bit FME.

 

............

 

Are u using ESRI formats a lot ie reading / writing GDBs etc ???

 

This is what I've found..........

 

................

 

Install 64bit FME - it runs alongside 32bit FME no problem.

 

Your 32bit install will now be found under C:\\Apps\\FME

 

Your 64bit install will be found under C:\\Program Files\\FME

 

This is useful to know as u can now disable an exe file if reqd eg rename Workbench to fmeworkbench.exe.DISABLED - now you'll know for sure which version will fire up when you double click a *.fmw file (also keep an eye on splash screen / look at help - about).

 

...........................

 

The good news

 

.............................

 

I've found that the 64bit version definitely runs quicker (as expected) and will hopefully run any heavy processing you have to do.

 

.........................

 

The bad news

 

...........................

 

You may find that not all your scripts (workbenches) will run under 64bit FME

 

(look at log carefully - red text).

 

Do u have an installation of ArcMap ???

 

If so you'll have the option under 32bit FME to Read & Write using the ESRI GDB reader / writer (APO) - in practical terms you get a few more read / write options for GDBs - but these only run under 32bit FME. Any workbenches using these readers . writers won't run anymore under 64bit FME

 

Solution is simple:

 

Redefine your readers and writers to the generic FME geodatabase readers / writers (API) - these workbenches should now run under both32bit and 64bit FME

 

Help files / FMEpedia articles suggest adding a new SDEHOME system variable. I tried this but it didn't work for me. I found solution above did work (redefining readers / writers from the ESRI versions to the FME (API) versions).

 

..............

 

A few more readers / writers I had to redefine also eg MS Access

 

...............

 

In Conclusion

 

I'd recomend using 32bit FME until you really have to run 64bit FME if your swapping files with colleagues / processing ESRI formats

 

If using 64bit FME use the FME readers / writers (API)

 

................

 

If Safe could align both versions it would be hugely appreciated (ie make all readers / writers work under both versions.

 

.................

 

Hope this helps

 

Regards

 

Howard L'

 

 


Thank you Howard for your information.

 

 

From what I've read on the other topic and what you wrote, I guess one shouldn't assume a too big performance gain. It that case, I guess I will stick to the 32bit version, which all other colleagues of mine use as well. 

 

We don't use ESRI geodatabases, but the exchange of the workspaces is a point which is relatively important. If this isn't ensured, I cannot switch to the 64 bit version. But so far, 32bit works quite well.

 

 

Kind regards

 

Thomas

 

 


Just to further clarify Howard's response - particularly relating to the Esri and Microsoft formats

 

 

The issue is that traditionally Esri has had ArcGIS Desktop which has always been only a 32 bit product. The ArcObjects library which we use for all our processing comes from here and only 32 bit FME can make use of it. Actually this is really a Microsoft problem - 32 bit only works with 32 bit.

 

 

Now Esri has come out with ArcGIS Server which is a 64 bit product so now there is a 64 bit ArcObjects library available but it requires that ArcGIS Server be installed on the same machine as a 64 bit FME. Again the Microsoft problem - 64 bit only works with 64 bit.

 

 

Similar behaviour will be experienced with the Microsoft products such as Access and SQL Server and also the Oracle formats because they all require client libraries at the correct bit level. Only Oracle is friendly enough to allow you to have both 32 bit and 64 bit clients installed side by side. Microsoft not so much - it will ony allow you to have the 64 bit native client or the 32 bit native client - hence causing the problem with Access

 

 

So Howard is correct in that he could replace his File Geodatabase (ArcObjects) reader/writers with the API reader/writer and then the workspaces will work in both versions - however there is reduced geodatabase functionality by doing this. Or he could install ArcGIS Server alongside his ArcGIS Desktop which would make the ArcObjects reader/writers work in both versions. Some customers install FME Server on an ArcGIS Server machine rather than install ArcGIS Server on a desktop machine and use this process for the 64 bit workspaces.

 

 

I am sorry we cannot make this any easier but it is somewhat out of our hands - we try to do the best we can with what is available.

 

 

Kind regards,

 

Robyn Rennie

 

FME Desktop Support Manager

 

 


To supplement this thread here's an excerpt from some correspondence I had with Howard on this topic that others might find useful:

 

 

An approach you might want to consider adopting is instead send jobs to an appropriate FME Engine depending on what it contains and how you want it to perform. For example anything with ESRI formats goes to your 32bit FME engine, anything else goes to your 64bit install. You can do this in a number of ways. Heres a couple of examples... use the SystemCaller, my attached CustomWorkspaceRunnerMethod.fmw workspace essentially creates you a bespoke WorkspaceRunner that allows you to determine which FME to hand the job off to.

 

 

Alternatively the batch file Env_Var_Method.bat shows a simple approach that you could use to set your PATH environment variable before you run the job...

 

 

Examples here:

 

http://goo.gl/x5BbnG

 

Cheers Dave

 

 


Reply