How many ElseIf's do you have in the "....and so forth" portion?
If you do more than about five or six ElseIfs, you really should consider something along the lines of CASE statement.
Next, what isn't clear is whether there is more program structure outside what you showed us. It seems that there has to be, but since you didn't show us what else you were doing, that is hard to tell.
Next, there is the funky little file sort issue. You can do this all in a single pass, perhaps, but it is not clear where you are going with this. In particular, what you are going to do with "strPictures" when you have built that string? As well as where strICN comes from and what it means.
Some random thoughts here...
Your speed problem comes from having to search the directory several times based on the outer ICN stuff. But directory searches can be terribly expensive in time (as you are finding out).
If you sort the returned filenames from the filesearch and made the search based on *.JPG, then you can keep track of the similar names and build the string strPictures on the fly in something more like a one-pass algorithm.
At least presumably, the first name in any sequence is the "base" name and all other names are that base + A, B, C, etc. You've already asked for the names to be sorted.
So start a loop with strPictures empty and create something called strBase. Make it empty, too.
Now step into the .FoundFiles list one file at a time with a "definite count" determined from .FoundFiles.Count.
On the first step, your base is empty. Make the base equal to the file name portion of your returned string. But don't do anything else with that yet.
On the next step, see if the name you have in this file matches strBase + the letter A (or B or C or whatever, you can set up another string thing to predict the next expected name if they are that predictable...) If it does, you just update strPictures.
Now if you see a name that looks like it must be a new "base" name 'cause it doesn't partially match the previous base, you could do whatever you were going to do with strPictures before you add in the new name. Like append it to your table or update something. Then erase the strPictures string and load the new strBase name.
When you reach the end of the loop, if you have not emptied strPictures one last time, you have to remember to do that, but otherwise you are done in only one file search.
My way of thinking is, if you let the table drive the algorithm, the repeated directory search is gonna eat your socks. But if the potential strICN happens to match the strBase contents and is also a key in the table, you could do the loop across the results of a single file search and use strBase to select the record you wanted to update using keys - a much faster item to consider. Not only that, but if I read correctly what you were trying to do, my suggested loop only updates when you find a name not consistent with previous name sequences - so you don't have to touch the DB that often, either. Does that make sense in your context? Even if that is not exactly right, look at rethinking what it is that will drive the outermost loop. You want the fastest thing INSIDE the nested loop structure and the slowest thing OUTSIDE the inner parts of the loop.
