It's possible but the problem is the report is telling you you have too many fields so even if you split it into multiple tables and you bring all those tables into a query and you bring that query into a report it's still going to give you too many fields. We're not talking about records here if you have 40 members then you have 40 records the error is saying that you have too many fields like first name last name and so on.

It appears, after searching the web, that you might be having issues in one of several places.

You may be having issues with your db itself.
Back up your db.  Then do a compact and repair.  SeeCompact & Repair , Compile , and the Troubleshooter.

If that doesn't fix it. You might be having issues with the structure of your tables / queries.  There is a limitation of 255 fields in a table, and depending on your joins,  etc., you might be exceeding that limit as it applies to the reports as well.

Take a look at those two things first.  You might need to do a screenshot ( Image Uploads ) of the actual error as well as the report in question in design mode for us to help you further.

Hello Scott and Richard, splitting table does not help.   This one report is a Regular Meeting Report is very structured. The database entry data form turns a multi hour effort into just a few minutes.  I think it will be a game changer for the Secretary.  The problem is that the report indicates 'Too Many Fields'.  The Tables for all Journal Activities have two or maybe three parts; a header table, and a detailed table that holds the differ data.   The Header Table is used in the Calendar as basic data.  It displays only 'Date Time, Event Type, Comment' field data.  It is also used in a EOY Report sent to members and on to Management.  It has only the 'Date Time, Event Type, Comment' field data and a couple added fields.  Basically, just a list of events the lodge did throughout the year.
The second part is detailed information about the event.  It is part of a Meeting Minutes Report sent to each member of the lodge after each meeting.
Event Examples:  Standing Business Meetings, Regular Meetings, which have a very structured format.  Perfect for a database report. Standing meeting's Structure is not complicated and does not trigger the 'Too Many Fields' error.  The other events; Social, Charity, Candidate Interviews, Other Lodge Visits and Rehearsals are also relatively simple.  Each of these events have their own Table and Form.  'Jur_125_xxxx0_T', 'Jur_125_xxxx1_T'and 'Jur_125_xxxx0_F', 'Jur_125_xxxx1_F'
Each event has at least one field that allows multi values and gets data from a query.  It selects Members names from our members table who are only active members, about 40 members.  The secretary can easily click and select members  that go into that field to be sent to the report.  In the Regular Meeting Form, I have three such Fields; Members Attending, Apologies and Visitors.  Attending and Apologies are the same Combo Field data.  The Visitors are drawn from a different data table.
The questions are:
The 1st Table 'Jur_Regular0_T' must link to the second and possible third detailed table 'Jur_Regular1_T' and 'Jur_Regular2_T' as a one to one relationship.  How do I do that?
With all the Multi Value Combo fields, what is the best way to get around the 'Too Many Fields' error. If I split the report into two, how do I run a single report that has both parts?
I need to keep the 'Jur_xxxx0_T' tables separate as it is used in the calendar and a separate EOY Report.  The end of year report will be generated by appending all the Event Tables xxxx0_T and running a simple report.  The Calendar is generated as events happen.  Also expected events in the future can be entered into the Calendar.  Detail associated Tables would be entered later but not in the calendar.

Hi William, you can split your report into multiple parts.  Each part is a smaller report that doesn't exceed the 255-field limit.  Then put them together as subreports.  When your report gets the "too many fields" error, it is really the underlying recordsource that gets the error.  So you not only need to split the reports, but also split the recordsource (query) as well.  This can get fairly involved if you have fairly large and complex tables and queries.

Hello Kevin,  I managed to combine the table into two different tables and Queries.  How do I set up the two queries into one report?

To do that, you create subreports, similar to subforms (in fact, it is the same button on the ribbon).  For instance, you create a report for Query A, and call it Report A.  Create a report for Query B, and call it Report B.  And so on.  Then you create a final "main report", and drag Report A, B, etc., to the main reports as subreports.  There is a limitation to subreports: they have to be laid out in a sort of "tile" format on the main report (see pic below), and they grow in size (unpredictably) depending on the number of records in them.  So this puts a limitation on the overall layout of your final report.

Thanks Kevin.  I'm doing that now

I had to redo the Forms for this Meeting Report.  To give me three separate forms that link to each other.  I hope it is correct. It seems to work for the testing I've done.  Is this correct for a one to one relationship between these tables and forms? Again I want to use the Jur_125_Reg0_T later with other  Meeting Types in the Calendar and EOY report.  Hopefully this should give me the three sub-Reports that do not have an 'Too many Fields Error'.  Thanks for that Insight.

Hi William, you are using inner joins in your 1-to-1 relationships.  An inner join will only show records with common IDs on both sides of the relationship.  So you need to make sure those 3 tables contain the same IDs.  Otherwise, some records won't show.  This is the caveat of this kind of relationship.  To avoid this, you usually don't split up tables unless it is really necessary.  Those 3 tables don't seem to have more than 255 fields.  Must they be split up?

Hello Kevin,  Sorry if this is over kill but here is a much data as I can give about the problem.  I really looking for just direction on this.  
I need to structure the all Meeting tables so I can use the Table0 which only have minimum data;
The ID for all the body tables.  Table 0 has Autonumber PrimaryKey.  The body tables are linked to that ID.  One Table0 to one set of detail body tables. One to One.  I've never made a one to one link.
Most Meeting Tables, Forms and Report will only have two tables.  As they are relatively few fields.
Only the Regular meeting which have a strict format and number of fields.  Also, a number of combo fields. Three with multi field combos with a total greater then 255 fields.  
The different meeting type table0s will be used in the calendar program and a EOY Journal.
What is your advice?  And again thanks. This is the last hurtle I need to complete on the database.

Hi William, you may consider migrating to SQL Server, which allows 1024 columns per table and 4096 columns per query (queries are called "views" in SQL Server).  Microsoft offers free versions of SQL Server: https://www.microsoft.com/en-us/sql-server/sql-server-downloads

If you stay in Access, my advice to you is the same as before: try to split up the data into subreports and arrange them in a tile format on a main report.  Your picture shows only one page of the report, and I can't tell if a tile format can be used there.  It all depends on the layout you desire.  If your layout requires data from different recordsets to be "mixed" into one small section of the report, then using the tile format may be difficult.

Another advice: consider re-designing your tables to minimize the number of fields.  One way to do that is to turn columns into rows.  For instance:

Instead of having a table that looks like:

EventType    DocFileName    Location   Comment   .... and 200 other columns
Regular Meeting   Reg-23021619   The Tauranga Lodge    Test

Make it look like:

FieldDesc     FieldValue
EventType     Regular Meeting
DocFileName     Reg-23021619
Location     The Tauranga Lodge
Comment     Test
...and 200 other rows

You reduce 200+ columns to 2 columns.  Having few columns makes a table easier to manage.  I've rarely had a table with more than 30 fields, and I can't imagine managing one with 1024 fields even if SQL Server allows it.  In a relational database, it's better to have lots of rows than lots of columns.

Yes, re-designing tables usually means you have to re-design your forms and reports.  So this needs to be carefully considered.  Would more columns be added in the future?  If you somehow could avoid the 255-limit this time, might you hit the limit again in the future?  If you might, then anything other than a table re-design would just be a band-aid solution.  Would it be worth your time to re-design and re-code your forms and reports?  You need to consider all the positives and negatives that pertain your specific business before you can take my suggestion.

Thanks Kevin,  You gave me a lot to think about.  I think this was very helpful.

William
I see that you have used Multi Valued fields in multiple places.  The first place I would start is there.  Get rid of those and properly set up your tables.  This type of field is known to cause issues because of the way MS handles them in Access.

Evil Access Stuff

Multivalued

Normalizing Data

Yes I see multivalued fields as well as calculated table fields which are also a big no-no. Those should be done in queries. And in my almost 30 years of building Access databases I've never needed that many fields in a single table. You should really consider breaking some of that up and making sure your data is properly normalized.

Thanks Every one.  I broke the record into three but real fix was the IDs in Sub Tables was not assigned Primary Key.  Ugggh.  Sorry Richard missed that part in the video.