Feature: Add GUID to Operation to distinguish distinct `Operations`

[hecon5]

The new log will need to use a unique value to identify what operation is being performed, especially if the operations are paralleled or concurrent in the case of build runners or just running a build for two different Access programs at once.

I propose using a GUID, as Access can use this value natively in a field, in testing I was able to generate and use them and restore the GUID value fairly easily.

I've based my solution on https://nolongerset.com/createguid/ with some tweaks to make it readable and usable by other functions should they decide to use it.

There's also https://nolongerset.com/getguidbasedtemppath/ which lays out getting a temp file for the log, but I'm not convinced that's the way to go either because of the potential for creating tons of scattered log files if Access bails out.

With that said, since I don't have an account to post to @mwolfe02 blog, here's my initial code and post to there: I'll put together a PR to handle this. I'm going to have it be separate from #654 because it is useful outside the scope of the log as well and parsing GUIDs is useful in other areas: for instance, our DB uses GUIDs and the Addin sometimes garbles them when spitting them into JSON.

I did discover though, that the way Microsoft parses the GUID into text will end up with the field value being parsed to something completely different than the native value if you use his routine above, especially if you intend to take the display value and parse it back into a GUID field value for comparison against a server field value. It won't matter if you're just generating a GUID and don't need to compare to another, but I think it'd be best to just use the built in parsing and writing tools; this ensures consistency and not having to re-engineer something else reduces error insertion possibilities, and didn't require any additional references beyond what his original code does.

We also found it to be [inconsequentially] faster [in our system environment].

This is because the GUID (as parsed by Microsoft Windows) is actually read as:

Public Type GUID
    Data1 As Long
    Data2 As Integer
    Data3 As Integer
    Data4(0 To 7) As Byte
End Type

I found this SO post to be indispensable in ensuring we parsed and unparsed a GUID correctly:
https://stackoverflow.com/questions/11177514/incorrect-guid-order

With that, some code to build and parse GUIDs:

Private Declare PtrSafe Function CoCreateGuid Lib "ole32" (ID As Any) As Long

Public Function GetGUID() As Variant
    Dim ID(0 To 15) As Byte
    CoCreateGuid ID(0)
    GetGUID = ID
End Function


Public Function GetStringFromGUID(ByRef GUIDIn As Variant) As String
    'GetStringFromGUID = StringFromGUID(GUIDIn) ' This adds a "{GUID { }" to the GUID.
    
    ' If you don't want the GUID tag, use this instead:
    GetStringFromGUID = Mid$(StringFromGUID(GUIDIn), 7, 38)
    
End Function


Public Function getGUIDFromString(ByRef GUIDStringIn As String) As Variant

    Const FunctionName As String = ModuleName & ".getGUIDfromstring"
    Const GUID_BRACE As String = "}"
    
    Dim tBracePos As Long

    tBracePos = InStrRev(GUIDStringIn, GUID_BRACE)
    
    If tBracePos > 0 Then
        getGUIDFromString = GUIDFromString(Mid$(GUIDStringIn, tBracePos - 38, 38))
        
    Else
        ' Brace not found, need to include braces.
        getGUIDFromString = GUIDFromString("{" & GUIDStringIn & "}")
    End If
    
End Function

[bclothier]

Just to consider:

GUID are great for uniqueness but they stink for correlation. So if I'm doing a build action, and it spawns 1000 operations. I somehow do a merge action on another project in parallel which then does 500 operations.

On the log table all the operations will be entwined but ultimately if I'm troubleshooting my build action, I only care about the 1000 operations from that action, not 500 operations from the other action and I would want to know which operation came first, next, and after that, and so on.

With GUIDs, I would have no idea. But with autonumbering integer, I can at least determine the sequence even if the numbers aren't contiguous. Similarly, I can filter on actions with tricks such as MAX() or maybe MAX()-1. That makes it much easier to look through the log file and reason about the sequence.

And having only two 32-bit integers as autonumbers means that it takes 64-bit which is half the size of a GUID (128-bit).

[hecon5]

So, the log already has an autonumber for EntryID; but what I found is if you managed to spool up two operations (a build, and export another), the log that gets exported for one will have operations from the other intertwined.

Each Build or Export Operation has just a single GUID; so you can do a match, which seems to be fairly fast, and more importantly, the exported log details don't get intertwined using the external log file.

I just updated the PR #654 with some of how I'm doing this, it seems to be fairly quick, as far as I can tell.

The Operation.OperationGUID only gets refreshed after you complete a whole operation (like at the end of Build or end of Export, or if it doesn't exist at all); it stays static otherwise. So for instance if you open up the Addin, change some options, save them, then run a build, the GUID that was set when it first loaded should match.

[bclothier]

Ok, I think I'm probably misunderstanding the terms - I was thinking of operation in terms of individual actions such as "open file", "export as text", and if I understand you, those will have an unique EntryID for sequential sorting. In this case, the GUID to unify them all is just fine.

[hecon5]

Correct: The GUID in the log table isn't an autonumber, it's fed in from the clsOperation.OperationGUID value. The GUID stays until you complete the build/export/whatever.

Example: you load up the addin, start an export, this exports 200 forms, and adds 2424 (hypothetically) log entries. The last step in the Export is Operation.Finish which will rotate the Operation.OperationGUID. All 2424 log entries will share one GUID value, and the next export will share a separate GUID.