Split Forms

[Thales750]

Does anyone use Split Forms, and if so, what is the, how, when ,what, or why?

 

[Ranman256]

Never. Regular forms have everything needed and wont confuse folks.

 

[KitaYama]

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?

 

[GPGeorge]

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.

 

[Minty]

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.

Emulating the split form

Like many users of this forum, I abandoned split forms a long time ago as I found them difficult to adapt if you want to modify them in any way In a recent thread another user wanted to keep the idea but to emulate it using a single form with a continuous subform. See this thread...

www.access-programmers.co.uk

 

[The_Doc_Man]

Never justified the "Why" so never tried, and thus cannot offer the "How, When, etc."

 

[theDBguy]

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!

 

[isladogs]

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)

 

[Pat Hartman]

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.

 

[arnelgp]

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.

 

[KitaYama]

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.

 

[GPGeorge]

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?

 

[KitaYama]

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.

 

[NauticalGent]

My own experience with them:

Split Forms: Just. Say. NO!

Trust me on this one, they are evil. That is all...

www.access-programmers.co.uk

 

[Pat Hartman]

Just wanted to say we have a sql server BE and we also have a lot of split forms.

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.

If you are binding them to tables or naked queries, I would think twice about them. Access sucks all the rows of the table down to memory on the user PC and works with the data locally with constant checkbacks to the server to refresh the data so you may as well be using ACE as the BE because you get no benefit from SQL Server and if the tables are large, you are causing a lot of network traffic to support these forms. This is one of the reasons DBA's hate Access. It's like a straw just sucking lots of data constantly when the forms are not specific with what they select.

 

[KitaYama]

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 *.

 

[GPGeorge]

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.

 

[KitaYama]

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.

 

[GPGeorge]

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?

 

[isladogs]

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

Emulated Split Form

The emulated split form was created as a project to overcome the difficulties inherent with the built-in split form supplied with Access

isladogs.co.uk