Although it is ugly, you could handle this pretty easily using some VBA code that runs from a general module. You would have to make it a public function if you wanted to run it from a macro. The function could, of course, just return a blanket Boolean TRUE if you didn't care about much else.
The approach I would take is as follows. Help topics you will need are in italics.
1. Write some VBA code to Open the text file. (So make the text file have a predictable name, maybe by renaming it based on your choice for the file name.) Open a recordset (.OpenRecordset method) to some handy table that contains what you need to keep for this operation.
2. In a loop that is protected by an On Error Then .... clause, start reading lines with InputLine
3. Using the InStr function, locate features in the line.
For instance, keyword "$KEY" is usable for an InStr search to identify a new record. So you would identify a new key, find the stuff between the left and right parentheses, and use the Mid$ function to extract that. Don't forget to allow for the parentheses occupying space in this substring.
4. If it is not a $KEY line then it is either a blank or a UID line. The blanks you can just flat skip. Use Len to identify that the line you just input was nil.
5. For the UID lines, it is hard for me to know if the ALLOW clause argument is meaningful because it doesn't look like a valid table name or data element name. In any case you can again extract the parenthetical material by using InStr to locate the left and right parentheses in order to pick out the pieces-parts. Note that InStr has a "start from here" argument, which is how you would find the second set of parentheses if you need that information.
6. Every time you get an UID ... ALLOW ... line parsed out, do a .AddNew method to the recordset you opened earlier. Populate its fields with the key, uid, and allow arguments. Do a .Update method on the recordset.
7. When your "On Error Then..." trap trips, close the file (Close statement) and the recordset (Close method). Evaluate the table afterwards to see if you got the number of records you expected to see. From there, you can use queries to take it farther in terms of reports, counts, etc.
You might have to run this code a couple of times if you have some abominations in the table. For instance one of your UID lines has an allow without any parentheses. So if you HAD to have something there, you would have to either flag the line or toss in a default value.
I would not have suggested this for truly free-form input, but your input is decidedly NOT free-form. It has enough syntactic and semantic markers to allow a simplified approach.
