These fields look like they contain comma separated values but in fact are a representation of what has been hidden from the user and designer. Access creates what is basically a properly normalized table for the data, but you not only can't see it, querying a mvf can be a pain. You can end up with multiple unwanted records because there are multiple values that fit the criteria. Mainly though, no other relational database schema will accept them, so if you ever want to migrate your app to one of these platforms, you cannot.
That being said, all that you need to do is what Access is doing for you and hiding - create properly normalized and related tables. This is very simplistic, but should serve to explain:
This is what you see
DEPT
|
LNAME
|
sales |
Smith, Brown, Adams |
This is what you should create, instead of Access doing it
DEPT
|
LNAME
|
sales |
Smith |
sales |
Brown |
sales |
Adams |
NOTE: the examples are not meant to suggest any particular table design for your db; they are only for answering your question on how to avoid the use of mvf's. You are probably wondering why have these at all if we refrain from using them. The only answer I've ever seen that makes sense on that is that they were developed to support SharePoint lists. Otherwise, they can be a PITA and make little sense when you can create a properly normalized and related set of tables that can be migrated to other platforms.
I also don't arbitrarily upload from other sites thus I haven't viewed your file and can't suggest what it is you need to do. You can always compact a copy of your db and zip it. Usually that will compress it enough so that you can upload it here.
The more we hear silence, the more we begin to think about our value in this universe.
Paraphrase of Professor Brian Cox.