You can do this by storing the records of the file as memo fields, then putting some file discriminator (i.e. a key that says which file it belongs to) and a position discriminator (i.e. line number).
You would need a table to hold file names. Another table holds your records.
In VBA, define the file name by writing it to a recordset with a unique key. Do the .Update and then copy out the key.
Now you would open the file for input. Read the input line. Start counting line numbers. Store the file key and line number key along with your memo field that is your actual file record.
OK, now that I've answered your question, the question of whether this is a practical thing is separate. If you are doing it to learn or play around, well and good. If you were hoping to hide something from someone as an added layer of security, that might be OK if you did encryption along the way, maybe...
BUT if this is supposed to be productive, you need to be aware that you are adding a layer of obfuscation that will eventually frustrate you in trying to get something out. Fer instance, if you are storing a file in C++ language, you cannot compile it while it is in Access .mdb files. C++ wants a separate file. The essentially free-form data that is a source program rarely is consistent with any sort of decent data storage algorithm that one might use with Access.
AND - there is an easy path to something called 'database bloat' by using such methods as OLE encoding. Many people use OLE with the "embedded" option, but this way leads to databases best described as "beached whales." They won't compress much if at all, they are susceptible to problems if you ever upgrade the program being linked, and as they grow, they tend to require more and more of your system's resources.
To be specific about the latter...
Suppose you have several OLE files and you open the DB. If your DB has grown to 500 Mb, your SWAP FILE has to also be 500 Mb + the size of everything else that Windows wants to store in memory in a running system. Which is VERY OFTEN another 100 Mb or so. You might well have that much disk set aside, but beware of the need to keep your disk defragged if you are going this way.