Build hangs on importing linked table having invalid path.

[joshbooker]

I found build hangs on importing tables when we have a linked table with an old, non-existent path.

No error pops and it hangs indefinitely 'not responding' with high cpu. I was able to delete the respective tbldefs files(s) and remove the same from the index.json file and the build worked rather fast as expected.

It'd be nice if the error was handled gracefully. "UNABLE TO LINK TABLE BLAH. PATH NOT FOUND" Continue?

Thanks for this tool. wish I knew about it years ago. keep up the great work!

[joshbooker]

possibly related: #307

[joyfullservice]

Thanks, Josh! I will see if I can test this on the latest dev build to see if it is still an issue. Like you said, it would be helpful to handle this condition gracefully.

[joyfullservice]

I was able to test this using Testing.accdb by renaming the linked CSV file so the build would not be able to locate it. The add-in showed the error on the build summary, and the full paths were listed in the log file. I did find a related issue where a custom object description could not be applied to this object because it was not created during the build, but I will address that in another commit shortly.

There may be some types of errors, such as ODBC connection timeouts that we may not be able to easily trap before they go into a timeout phase. I am open to suggestions on better ways to handle those, but I would guess that these should be pretty infrequent on actively developed projects.

[joshbooker]

Thanks Adam. I've tried to recreate the problem with an Access linked table using testing.accde (after removing the code that relinks tables to current path on open) but it handles a bad path gracefully with error and continues.

Also, I tested build of my export after creating the file/tbl at the bad path (making it good) and the build ran fine. Then I renamed the file and re-build hangs again.

Further, after crashing out of Access and opening the partial built file I can see it hung on the table in question due to import sequence.

So either fixing the bad path or deleting the table from the project json builds successfully.

Why?

Tried to debug in the add-in and ImportLinkedTable function is definitely throwing 3044 error at dbs.TableDefs.Append tdf as expected but I cannot debug any further.

Mystery I guess. Thanks again.

[joyfullservice]

Thanks! It looks like there are at least a couple more error numbers Access uses when it has problems linking to a Microsoft Access database table. I added these to the error handler, so that should fix the issue, at least for these two situations.

I need to review things a little further because the following CatchAny call should have trapped the error without an application hang...

[joshbooker]

Not one to give up i tried to debug the addin further. I got Error: 28 out of stack space after CatchAny in function ImportLinkedTable. When I stepped into CatchAny it indeed caught the error 3044 as expected but coming out got Err28

        If Catch(3011) Then
            Log.Error eelError, "Could not link table '" & dItem("SourceTableName") & "'", _
            ModuleName & ".ImportLinkedTable"
            Log.Add "Linked table object not found in " & strFile, False
            Log.Add "Connection String: " & strConnect, False
        ElseIf CatchAny(eelError, vbNullString, ModuleName & ".ImportLinkedTable", True, False) Then
            ' May have encountered other issue like a missing link specification.
            MsgBox Err & ": " & Err.Description & vbCrLf & "File: " & strFile
            Err.Clear
        Else

I prevented Err.Clear on CatchAny call and added the MsgBox and Err.Clear and upon clicking ok to the msg the Build continued and completed successfully.

The only side effect noticed is the progress textbox and build log had many blank lines (123-996) and the 3044 error did not post to either place.

Perhaps an endless logging loop(?)

Hope this helps

[joyfullservice]

Thanks! Yes, that is helpful, and explains why Access was hanging. It probably does have to do with the function that checks for unhandled errors going into a loop... I know I refactored that recently, and might have introduced a bug. I will look at this when I have a chance.

[hecon5]

@joyfullservice Is this solved?

[joyfullservice]

Yes, I believe this has been resolved. We can reopen the issue if we have any further problems with this.