PDA

View Full Version : ICM transportable databases



Kristian Ravnkilde
March 27, 2013, 03:03 AM
The process of creating a transportable daatbase in ICM (3.0 and earlier) seems incredibly slow and unreliable. I tried one the other week and had to leave it running overnight, even though I excluded the ground model and results. Some have failed altogether. I have also had supposed transportable databases sent to me that presumably seemed to have been created successfully, but were completely empty (the 90kb file size should have been a clue!). Is this a common experience?

Andrew Walker
March 27, 2013, 05:39 AM
The process of creating a transportable database in ICM (3.0 and earlier) seems incredibly slow and unreliable. I tried one the other week and had to leave it running overnight, even though I excluded the ground model and results. A lot will depend on the format (Personal or Workgroup) of the master database, how much data it contains and where the database is stored (this last point especially in the case of a Personal database). Processing is all done in memory. The process is so intensive that all user interactions (mouse clicks etc) will result in ‘Not Responding’ type messages while it’s working. Just wait, it will finish.


Some have failed altogether. If there is a lot of data to process ICM will give the impression it’s hung. If you interrupt the process (by accident or because you think its hung), you will corrupt the database you are trying to create.


I have also had supposed transportable databases sent to me that presumably seemed to have been created successfully, but were completely empty (the 90kb file size should have been a clue!). Is this a common experience? This is caused when the window containing the view onto the transportable database is not closed before the user e-mails or uploads the *.icmt file. The final thing that ICM does when you close the window is to compress the copied data and form the eventual *.icmt. If you don't close the window before doing something with the *.icmt you end up with a blank transportable database (i.e. just the file that was created at the start and no content). The same 'rules' apply for transportable databases created for CS, SD, RS and WS.

Kristian Ravnkilde
March 27, 2013, 05:51 AM
Personal database, on my local D drive. I've been watching the Task Manager, it only ever seems to use one thread to create the .icmt, and there's plenty of RAM to spare. It creates large temporary files, which seem to update every 2 or 3 minutes. The problem is that it stops you working in ICM for such a long time - are there any plans to speed it up?
"Not responding" messages I can deal with, I know that means it's working away and I'm getting very used to them with W7 (or maybe it's our network!).

Andrew Walker
March 27, 2013, 06:56 AM
..... are there any plans to speed it up? The Development Team are constantly striving to optimise all areas of InfoWorks. It's often the Mathematics and resulting Simulation speeds that grab all the headlines, but there's always a lot of work going on behind the scenes to see where the more mundane areas, such as copying data between Master Databases or into Transportable Databases, can be improved.

While on the subject of copying data between Master Databases, many people are under the impression that moving data between two Master Databases requires the production of a Transportable database first. This is not the case. Models and Results can be moved between a personal (standalone) database and a Workgroup database (or between two databases of the same type), without any intermediate steps. You just need to open the first database, then with that open, open the second database as well (File -> Open -> Open another master database). With both open, simply copy the data between the two. For large databases (anything over 2Gb), this will still take quite a long time and might result in ‘Not Responding’ type messages while it’s working, but you certainly don't need to put anything in a Transportable Database first.

Kristian Ravnkilde
March 27, 2013, 06:59 AM
Good tip. Too bad it won't work with databases on another firm's computers!