I won't say categorically that Access import wizards won't handle this, but the gyrations you would have to perform, the hoops you have to jump through, would be very complex. You would do better to parse this out using VBA code underneath your event that you mentioned.
In overview, what you have to do is learn how to parse things. How you parse your records will drive how you store them.
If I were doing this, my code would be something like this:
In my event code, I would call a separate subroutine in a general module even though it is used in a class module. I do this for context control and better error handling - tends to localize bugs this way.
In the subroutine, I would open a recordset to the table in which I want this stuff to go. Then I would use the VBA "Open" verb to open the audit log file.
OK, now I would go into a parser loop. I would read a line (Input Line verb in VBA) to a string variable.
I would look for the line that began with "Date:" and also contained "Time:" - both of which can be confirmed with InStr function calls. Using the results of the InStr searches, I would know the positions of the strings "Date:" and "Time:" - and from Len function I would know the length of the whole string. So I could generate a Mid function call to directly extract the date and time. Remember, at the moment these are still STRINGS.
OK, now I've got a "header." Start reading the lines, looking for the expected keywords. For the lines with a Transaction #:, you know the start of the number. (It's just after the first colon.) You also know you are looking for a Cashier ID:, and again you know where that starts and where it ends ('cause it's a constant string). You know the length of the string, so you can find the cashier ID.
Read the next line. It tells you your computer. With InStr function to confirm it, you also then know the end of the constant Computer: string, which is after the colon. With the Len function, you can compute the dimensions of the computer ID code to again use Mid function.
The last line is where your work will reside. When you have a Sale Recorded and a transaction, you will have a total, and you can extract that total the same way as I described earlier. When you don't have a transaction total (no ":" and the line doesn't start with "Sale Recorded" !!!!), the entire line looks like it is the event message. Whereas with "Sale Recorded" you have a data field in the form of the sales total.
You don't say whether a fifth line is possible, but if it is, you would keep on reading until you found a blank line. Stop for a moment, do a .AddNew on the recordset, fill in the fields of your recordset, update the recordset, and keep on parsing. When filling in the fields, be prepred to use one of the many conversion routines. Like, if you are storing dates and times in a single field, you can convert the two strings via concatenation and convert them to a date with CDate$() function. It's in the help files. Be sure to set up the tables to allow blanks, zeros, or nulls (as you choose) to
Trap on <EOF> of the input file. When you hit <EOF> you are done. I don't use this method in Access - but I do use it in another application on another operating system. The trick is to be sure you know all of the possible messages you can see in that fourth line and which fields in the first three lines could be omitted. (Like "Transaction number" when the cashier rings up a "No Sale" and voids it all.) Once you know all possible responses, you have it sacked.
All that is left is one of the old programmer rules: If you opened it, close it.
So close the text file and the recordset. Now you have flattened your audit history from four lines to one record.
'tain't pretty, but it works.
