OK, let's talk "mechanisms." On an access form, there are two major ways that controls on the form (text boxes, combo boxes, check boxes, etc.) get populated. The two methods are radically different. (There are also a few minor ways, but I'll avoid them at the moment.)
#1 - BOUND forms - you name a .RecordSource for the form, which can be a table or query that "exposes" multiple data elements (i.e. fields). Then for each bound control, you name a .ControlSource that names a field associated with the .RecordSource. Access has these "events" in which certain highly specific things happen at certain times. The event relevant to this discussion is the Form_Current event, in which Access (behind the scenes) visits each control on the form. For each control that is bound, it plucks a copy of the value from the field in the .RecordSource that was defined by the individual .ControlSource - and at the end of that once-through, all controls that were GOING to be loaded HAVE BEEN loaded. If needed, the user could have also entered a link to a Form_Current event routine in which some VBA code might load controls that were omitted during the Access scan for BOUND controls. Between Access automatic control population and a possible Form_Current routine, that is how you normally populate data into forms.
#2 - UNBOUND forms - much trickier - because certain events (Current being one of them) don't occur for unbound forms. Therefore, someone has to write VBA code to communicate with the intended data source to extract and load values to controls. Your form MIGHT have some buttons that you can click to drive it and trigger it, or it might be more fully automated. Though with an SQL backend, I think it has to stay synchronized with some data cursor so what it does will be more "episodic" i.e. dependent on something the form's user does.
Sounds like what you have is case #2, which means if you want to find out how something gets loaded, you have to open the form in design mode, then in the ribbon switch to database tools, then open the code / macros page. Somewhere in that part of the DB, you will find the code that loads stuff. I'm GUESSING that the code in question will deal with some kind of recordset, in which case the starting point for that sequence is whatever code segment executes a .OpenRecordset function, which will name an SQL-resident table.
Here is the kicker: By having unbound forms, you are automatically starting at an extreme disadvantage, because MOST of the time, Access will do exactly what you would want it to do through BOUND forms. Therefore, whoever set this up was either (a) ignorant of how Access works with SQL or (b) is well aware that Access doesn't do what the original author wanted. So in either case, you are dealing with something very complex.