Split Forms

Thales750

Formerly Jsanders
Local time
Today, 15:45
Joined
Dec 20, 2007
Messages
3,708
Does anyone use Split Forms, and if so, what is the, how, when ,what, or why?
 
Never. Regular forms have everything needed and wont confuse folks.
 
wont confuse folks.
Why folks would be confused?
You have a single form above with a list at the bottom that shows all saved records from the last time the form was opened?
So the user can see what was the last record he saved and its contents.

What is confusing?
 
Last edited:
They are pretty rarely used. I had one occasion in a 20+ year career as an Access developer to use one. It was in a situation where a daily download of records from a website had to be reviewed and either accepted or rejected for inclusion in the production tables. It was handy for the users to have the single view form to see all of the relevant data laid out in a display with labels, along with a datasheet that made it easier to pick one record from a group of 20 to 50 for more detailed review in the form view section. We probably could have implemented a different approach as well, but it did seem to be useful in that context.
 
They have some strange limitations as well.
There is a very long thread on here referencing the issues and some experienced members trying to work around them or create a better version of the same layout.

This thread ties it up nicely.

 
Never justified the "Why" so never tried, and thus cannot offer the "How, When, etc."
 
Please don't judge me, but I use split forms a lot. However, not in the way they were originally intended. To see what I mean, download any MS Template and see how they use split forms in them. Cheers!
 
Please don't judge me, but I use split forms a lot. However, not in the way they were originally intended. To see what I mean, download any MS Template and see how they use split forms in them. Cheers!
I know how MS use them in their templates ... but that doesn't tell me how you use them (not in the way they were originally intended)
 
how? create one now.
when? now.
what? you tell me.
why? why not.

I always use them!
If you are looking for some "special" trick that this form cannot offer, then it is not for you.
 
Last edited:
Please don't judge me, but I use split forms a lot
Is it a sin to use them?

I know about their limitations. And how hard working with them may be. But it doesn't mean they don't have their place.
I can understand when @GPGeorge says he hasn't used it in 20+ years. or why others have abandoned them. I think mostly because they weren't in a situation where they come handy.

I never use them but that is because my BE's are almost always SQL Server or are likely to need to be upsized in the future. WHY - because when the BE is SQL server, you would NEVER, EVER bind a form to a table (unless the table will always be very small) or a query with no criteria and filter locally. It defeats a major benefit of using a RDBMS as the BE. If you are going to download all the rows from the table/query and filter locally, that would be seriously poor practice with a RDBMS BE.
@Pat Hartman I don't have your experience and knowledge and I can't argue with you.
Just wanted to say we have a sql server BE and we also have a lot of split forms.
It helps the designers, the people in shop floor & machine operators to see which material, dimensions, Processes, tools, tolerances, machining conditions etc. they've saved.

Why should you bound a split form to a table? Why not using it just like a normal form? Open it with a filter that returns zero record, then set as filter in it's recordset in onLoad event.

Most people forget that the main purpose of a split form is having a list of saved records since it's last been opened.
The form is opened as data entry and every records saved is shown bellow. It helps our users to see which tools have been used, the tolerances and all other fields in previous rows. So they don't need to go back and forth between data entry and search forms.

This is a part of a split forms bound to a table with more than 2 million records. I don't see what is wrong with it.


2023-03-03_10-23-24.jpg
 
Last edited:
I actually said I used one once in 20+ years, but that's a minor quibble.

You can achieve the same functionality with a main form/sub form design and a combo box that filters those 2 million records so that only one is ever returned in the form's recordsource, not all 2 million. Not a minor thing, I believe.

What you see in the upper, single form, portion is the exact same fields as you see in the first row in the datasheet portion of te form. That's because it is the exact same record. If you move the focus to the second row in the datasheet view, the record displayed in the single form view changes to that same record, and vice versa.

That leaves me at a loss as to how you are seeing "a list of saved records since it's last been opened". What else is going on here to accomplish that?
 
You can achieve the same functionality with a main form/sub form design and a combo box that filters those 2 million records so that only one is ever returned in the form's recordsource, not all 2 million. Not a minor thing, I believe.
Yes I can. But why should I? When a split form without a line of code gives me the same possibility...

What you see in the upper, single form, portion is the exact same fields as you see in the first row in the datasheet portion of te form. That's because it is the exact same record. If you move the focus to the second row in the datasheet view, the record displayed in the single form view changes to that same record, and vice versa.
Exactly. And when I go to a new record, I have an empty form ready for inputting data...AND... I can see the previous records as a reference. I can check the previous tools, their properties, tolerances etc...

That leaves me at a loss as to how you are seeing "a list of saved records since it's last been opened". What else is going on here to accomplish that?
Nothing. Not even a line of code. It's a split form that opens as a data entry form.
You know for sure when you open a form for data entry, and start saving records, after saving each record you can move between saved records with page down/ page up keys. The form keeps all saved record since it's last opened.

In a split forms, the records (since the last time it's opened) is listed in the bottom section.
 
If you are binding them to select queries with criteria that limits the data retrieved, then as long as you don't have any problem with their quirks, use them if your people like them.
The forms recordsets are : SELECT * FROM MyQuery WHERE False;
Then in On_Loud event we have :
Me.Recordsource = "SELECT * FROM MyQuery WHERE " & Me.OpenArgs

We almost need all fields. Hence using *.
 
The forms recordsets are : SELECT * FROM MyQuery WHERE False;
Then in On_Loud event we have :
Me.Recordsource = "SELECT * FROM MyQuery WHERE " & Me.OpenArgs

We almost need all fields. Hence using *.
You are filtering the records then. And that's exactly the same thing you could do with a form in any other view. I get why you like it, though. It combines a standard single view form, with a datasheet view of the same recordset. Having one's cake and eating it too.
 
You are filtering the records then.
That was the answer for how we normally open forms.
The image you see above is a normal split form, not filtered, but set as input data. It's opened just like;
Docmd.OpenForm "frmMaterials"


I get why you like it, though. It combines a standard single view form, with a datasheet view of the same recordset.
Exactly. It prevents users switch between search form and input form
OR
Having both forms open at the same time.

One look, give them all they need. The form is kept opened the whole day, and as they manufacture more and more parts, they can see/check the change in the manufactured dimensions and used tolerances for Roughing, Finishing and other used tools.
 
Last edited:
That was the answer for how we normally open forms.
The image you see above is a normal split form, not filtered, but set as input data. It's opened just like;
Docmd.OpenForm "frmMaterials"



Exactly. It prevents users switch between search form and input form
OR
Having both forms open at the same time.

One look, give them all they need. The form is kept opened the whole day, and as they manufacture more and more parts, they can see/check the change in the manufactured dimensions and used tolerances for Roughing, Finishing and other used tools.
I wonder if one could figure out a way to do the same thing with a main form in single view and a subform in datasheet view, both bound to the same table? Has anyone done that?
 
Its already been mentioned but have a look at the emulated split form which has both single and continuous views using the same form.
No subform needed. Search feature built in.
A datasheet could be used instead of the continuous form if preferred but then of course a subform is needed
 
Its already been mentioned but have a look at the emulated split form which has both single and continuous views using the same form.
No subform needed. Search feature built in.
A datasheet could be used instead of the continuous form if preferred but then of course a subform is needed
@isladogs I've read your article several times in the past. I've always had a question and hesitated to ask. Now that you give a link to the article, I think I better ask it.

The following is from your link :

However, unlike the standard split form, the data can be filtered as well as sorted.
What does it mean?
Because I use a standard split form, I can filter it by :
Me.Filter=......
Me.FilterOn = True

OR

Me.RecordSource="SELECT * FROM qry WHERE " & Filter.

I can also right click a textbox and select one of Access default filter context menu items: , greater than,...Less than....equal to... etc,
And clicking each title, sorts the form.

The image I posted in #11 has more than 10 textboxes, listboxes, checkboxes, options and combo to filter the form.
And users are actually filtering the data.

So both Access default Sort & Filter tools & user defined methods can be used.
I appreciate if you explain what do you mean by above statement?

thanks.
 
Last edited:
@KitaYama
Split forms do have limitations and, IIRC many years ago that was one of the limitations.
However, I agree that comment no longer applies - you certainly can filter a standard split form

I will update my article at some point

Sorting was of course never an issue due to the datasheet view

Here are some issues that do still apply and which I will add to the article:

1. You cannot use a standard split form as a subform. Only the single form part is shown.
That also prevents its use in a tab control

The emulated split form works perfectly as a subform, including in tab controls

2. Standard split forms don't play nicely with automatic form resizing (AFR) and can give peculiar results like this
1677934238233.png


The display can be fixed by moving the splitter bar but its a PITA to do so each time
Emulated split forms behave perfectly with AFR

3. I use overlapping windows display & find it impossible to control the height/width of a standard split form.
It always appears too tall and wide
However, its fine if used with tabbed documents or maximized
 

Users who are viewing this thread

Back
Top Bottom