Unfortunately, there's difference between the indexing type for each field with the Create Index (you can't set it, it uses default settings), and the indexing I need to set. So I can't use that solution, but the question of the asynchrounousity remains.
So I'm stuck with 7" import time :-( (11 min was the 4 field fully all indexed, 7 min, is 1 minimal, 3 all)
Have you tried dropping the indexes, importing the records and then executing a Perform Find script step where you enter a search term (such as an asterisk) into each of the four fields before executing the find? The default behaviour is for indexes to be automatically created when needed, and a Find Request will trigger this.
This would get around your need to wait with your scripting, although I expect the indexing process will still take a reasonable amount of time.
Yes, but that's only postponing the pain to the innocent user when he uses the solution.
Plus, I need full indexing, on one of the text fields (the other 2 are numbers so full anyways), and to get this i would need to trigger partiel search.
I'd prefer a long setting up script ad then decent speed, than quick setup and then slowness while user uses it.
Moreover, and that the crux of the OP, Dropping / creating index seems unreliable because I can only hope my 5s pause will go well in real world. So I'd need a way to make those call reliable, with certitude about their finite state
1 of 1 people found this helpful
Have you tried creating the index via an ODBC connection with the Execute SQL script step instead of a plugin? It's been a long time since I've dropped and created indexes that way, but I'm pretty sure it at least used to be synchronous.
I imagine that creating an index is likely an O(N)LogN type function where N is the number of unique values in the table for the indexed field. Thus the time needed, whether synchronous or asynchronous will be a function of the number of records in your table, more specifically, the number of unique values in that field of that table.
Dropping index without "manage database" is useful, but what is the benefit on creating? You can create with finding records on the fields.
You have to.
Dropping the index, also sets the indexing to none (without automatically create index as needed option checked).
Finds only recreate index if the automatically create index as needed options is checked.
therefore after dropping an index, finds won't recreate it.
And, as i said, I prefer to set things correctly in the setup script rather than defering the slownes to the user
Hmm, I misread the SQL reference since it says
The PREVENT INDEX CREATION attribute is not supported.
I got it as "you can't prevent..." then "automatically create index" is always on after DROP INDEX.