Subscribe to this thread
Home - General / All posts - vbscript m9 continues to run after the program is shut down?
136 post(s)
#03-Dec-18 08:38


This was interesting behaviour.... I was running the vbscript on m9 in the the script runs for many hours (depends on the machine). It was taking too long to run so I shut m9 down.

But it appeared the script continued to run (all the cores were still working) and it showed the process still working in windows task manager in the processes tab.

I also couldn't reopen the project until I ended the process in the task manager.

I had this result on two different computers.


On a different note, it was cool to be able to run multiple instances of this script in multiple instances of m9 and for all the cores to be used by each instant. This did speed things up a lot.

Oh - also how do you get the sql to go over two or more lines. There is one other example for m9 on forum but I couldn't replicate it successfully.

I tried for the end of the line



and for the start of the line



And combinations of the above.

code - vbscript m9

' VBScript

Sub Main

Set app = Manifold.Application

Set db = app.GetDatabaseRoot()

j = 1

jmax = 400

text = "delete from efg_sdm_temp1;"

db.Run text


text = "delete from [aatest74 Drawing];"

db.Run text

text = "insert into [aatest74 drawing] (filename, val, geom, sp_id) select * from [sbrass_fe.aatest71 drawing] where sp_id = "&j&";"

db.Run text

i = 1

imax = 57


text = "delete from [temp2 drawing];"

db.Run text

text = "insert into [temp2 drawing] select * from [l10 4] where grid1 = "&i&";"

db.Run text

text = "insert into efg_sdm_temp1 (filename, efg_name, efg_num, tot_ha) select filename, efg_name, efg_num, rounddecs(sum(area_ha),1) as tot_ha  from (SELECT [s_Geom], [o_mfd_id],o_efg_name as efg_name,s_filename as filename,o_efg_num as efg_num,geomarea(s_geom,0) / 10000 as area_ha FROM CALL GeomOverlayTopologyIntersectPar([aatest74 Drawing] (filename,geom),[temp2 drawing] ([mfd_id], efg_name, efg_num, [Geom (I)]),0,ThreadConfig(SystemCpuCount()))) group by filename,efg_name, efg_num;"

db.Run text

i = i + 1

loop until i > imax

j = j + 1

loop until j > jmax


End Sub


8,648 post(s)
#03-Dec-18 09:15

Two quick comments.

First, what do you mean by "so I shut m9 down"? If you did successfully shut it down, then it was not still running--and you could not later have "ended the process in the task manager".

Secondly, the script is inefficient. There are better ways to achieve the purpose(s) here. If you say what those are, someone can help.

(The main thing is probably to avoid deleting objects, by using truly temporary tables.)

136 post(s)
#03-Dec-18 10:49

"so I shut m9 down"

Quick reply.

clicked on x in top right corner.

"Do you want to save changes?"


Exit Program

program screen shuts down


Process still running.

Attempt to load file again.

"Cannot load data".

This is repeatable.


Temporary table idea is interesting. Would be cool to see if it can go faster


8,431 post(s)
#12-Dec-18 09:19

First off, how to break a string into multiple lines in VBScript:

' VBScript

Sub Main

  Manifold.Application.Log "Hello, " _

    & "World!"


End Sub

(So, you have to use both _ at the end of the line to indicate to the script engine that the line doesn't end just yet *and* use & at the beginning of the next line to grow the string. VBScript is a bit clumsy in this way, other languages have shorter syntax for multi-line strings.)

Regarding the script still running after you shut down 9 - you started the shut down, this closed the UI and started waiting for the background threads to finish. The UI did signal to the background threads that they should stop whatever they are doing, but how soon until they notice depends on what they are doing. This is somewhat similar to how some of the long operations that track progress do not react to you pressing cancel immediately - they do react eventually, but that may take some time. It is much more complex with scripts, however, because while your particular script only spends time in Manifold objects, a different script could make a call into a third-party object that we do not control and who knows when that call is going to return, there's just no control over that whatsoever (terminating the call is too dangerous and risks losing data, so we never do that automatically and leave it to the user to terminate the process).

We are currently looking into making some of the long operations that we have more responsive to cancel, we will look at the scripts as well.

Manifold User Community Use Agreement Copyright (C) 2007-2017 Manifold Software Limited. All rights reserved.