Solved

Writing Geomedia Access WArehouse in FME 2017 ?

  • 4 October 2017
  • 6 replies
  • 5 views
lifalin2016
Rank
Userlevel 1
Badge +22

Hi,

I've just moved an existing process that writes to a Geomedia Access Warehouse from FME 2016.1 to 2017.1. Everything else is the same. And yes, both are run in 32 bit.

It seems to me, that the writing of this is very much slower than it used to be. The previous process (which also writes to an SQL Server) used to take less than an hour to complete, now it cannot finish within two !

I just ran the process manually, and especially the writing to GMAW seemed very slow to watch.

Has anyone else run into similar issues ?

My machine is Windows 10 Pro.

Cheers, Lars

icon

Best answer by lifalin2016 27 September 2018, 14:27

View original
-- Cheers, Lars I.

6 replies

dustin
Rank
Userlevel 3
Badge +26
We recently upgraded from FME2014 to 2017.1. We did not see any noticeable slow down in writing. How large are your output files, and which version of Geomedia are you using? Ours range anywhere from 10-60mb.

 

 

steveatsafe
Rank
Badge +11
Hi @lifalin2016, like Cartoscro I'm curious to learn about the amount of data and the GeoMedia version in use? Has this changed during your upgrade to 2017.1?

 

 

FME relies on the GeoMedia Objects for reading/writing to the Access Warehouse, but for the GeoMedia SQL Server - FME delivers the required files and do not rely on GeoMedia Objects of the installed GeoMedia application.

 

 

Can you test by splitting the workflow to see if it the writing to the Access or SQL Server that is slower?

 

Are you in a position to re-install FME 2016.1 and do the same like for like test on the same system? It would help to narrow down which part of the workflow is slower.

 

 

NOTE: You can have more than one version of FME on the same system, just ensure you install the second (or others) into a new folder.

 

 

Look forward to your response!

 

SteveatSafe
mark2atsafe
Rank
Userlevel 4
Badge +25
I did a quick check and there were only two problem reports fixed for 2017 that involved Geomedia. One was an interface issue and the other related to ignoring a flag when run from Server or the command line. Neither of those sound like they should have made the format slower. Do any other formats appear slower? Or is it just this one?

 

Oh, check if the order of writers is the same. If that's changed it could make a difference. What is the Writer Order parameter (Navigator window > Workspace Parameters) set to?

 

lifalin2016
Rank
Userlevel 1
Badge +22
cartoscro: The resulting MDB is 160 Mb, but I suspect it may include some empty space. A total of 270k elements are written into 4 tables. The version should be 6.

 

 

steve/mark: My original workspace stored identical data into 3 separate datasets: GM/Access, GM/SQL, and MS/SQL. The original order was GMAW, GMSW, Spatial, but I did reverse that before encountering problems. I have now split the workspace into two, 1st from source into MS/SQL, and 2nd from MS/SQL til GM (both sets). It seems to work as before, taking a total of only 40 minutes to complete.

 

 

And I do have both 2016.1 and 2017.1 both as 32 and 64 bit installed side by side, so the switch was only implemented by designating a different fme.exe to run the translation.

 

 

But I've found another issue that may have caused the problems. Another task may have been attempting to copy the MDB file while it was being written. How would that affect FME's output ?

 

-- Cheers, Lars I.
steveatsafe
Rank
Badge +11
cartoscro: The resulting MDB is 160 Mb, but I suspect it may include some empty space. A total of 270k elements are written into 4 tables. The version should be 6.

 

 

steve/mark: My original workspace stored identical data into 3 separate datasets: GM/Access, GM/SQL, and MS/SQL. The original order was GMAW, GMSW, Spatial, but I did reverse that before encountering problems. I have now split the workspace into two, 1st from source into MS/SQL, and 2nd from MS/SQL til GM (both sets). It seems to work as before, taking a total of only 40 minutes to complete.

 

 

And I do have both 2016.1 and 2017.1 both as 32 and 64 bit installed side by side, so the switch was only implemented by designating a different fme.exe to run the translation.

 

 

But I've found another issue that may have caused the problems. Another task may have been attempting to copy the MDB file while it was being written. How would that affect FME's output ?

 

Hi @lifalin2016 You might be onto something there. But I'm not certain. It's possible this might interfere with the writing performance. I'm curious if you'll be able to confirm this or not.

 

SteveatSafe
lifalin2016
Rank
Userlevel 1
Badge +22

Closing question

-- Cheers, Lars I.

Reply


Community Stats

28,731
Posts
109,528
Replies
36,565
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.