# Base form containing 100s of fields [closed]

Hello: Newbie here. I have a database with 100s of fields. I need to make a user friendly form to input into the table. I do not want the user to get bogged down scrolling up and down a huge long form.

Is there a way to break up the form into tabs and sub-tabs to the user can enter the field values in a easier and ergonomic way?

Any help will be appreciated. Thank you.

EDIT:

Hello: Apologies for cross posting. I was not aware that the two forums are connected. And now that post is 'locked' after a reprimand. Talk of trial by fire for newbies. :-)

@Ratslinger: Thank you for the suggestion to normalize the data. I certainly plan to break up the table for ease and efficiency. Right now, I am just wrapping my head around the features of OpenOffice Base. Furthermore, I did not want to bog down the original question, which still is open.

I understand Base's shortcoming for not featuring tabs. Thank you for the clarification.

I am now trying to use a macro which could possibly take the user to another form after entering preliminary information on the first form (just as @LSemmens alluded to). I created buttons after following the fabulous steps outlined by Shane Piper for creating a 'switchboard'. Upon activation, the second form opens successfully. Unfortunately, it jumps to record #1. Is there a way to prompt the macro to jump to the record being worked on in form #1? I am attaching a copy of my WIP database. Any help will be appreciated. C:\fakepath\DB_PatientData.odb

I hope I am clear with my question. Please let me know if you need more clarification. Appreciate all the effort and help you folks are providing.

@Ratslinger: I am attaching a 'simplified' version of the .ODB file.C:\fakepath\DB_PatientData Simplified.odb

edit retag reopen merge delete

### Closed for the following reason question is off-topic or not relevant by biarced close date 2019-10-15 01:49:01.641888

Hello,

Many 'Databases' have 100's of fields. However it sounds as if you have this many in a single table. If that is correct, you may have a design problem and need to reconsider. Further explanation will help.

There are no built in Tabs in Base. You can simulate certain situations with macro coding.

( 2019-10-10 18:18:56 +0200 )edit

If you are going to cross post, please mention this via links in each post to eliminate double efforts. Also posted here -> Buttons to open forms of same records

It is also curious as to why you never responded to the comment.

( 2019-10-14 00:30:00 +0200 )edit

Have had an initial view of the file. Your description is not what I can relate to the sample. There are some serious flaws in the design. First, what is the format of a patient number - ie NNNN or NN-NN or what? Another problem is going to cause major problems. In at least two table you seem to want to embed what seem to be a document. Using an HSQLDB embedded database will surely result in crashes after only a few records have been created. This is noted in many areas of this forum and others. Is it possible to just link (point to) the document stored in another location on the same computer? It would still display in the same manner on the form but eliminate many problems. If not, you must consider a totally different approach with which database is to be used.

( 2019-10-14 17:49:19 +0200 )edit

1. I was thinking of plain simple integers for PatientID. So NNNN would be fine.
2. It certainly is possible to link to the attachment in another location on the computer. Not a problem. I will make that change as I go on with my learning.
3. Sequence of processing is: Let's say the user is entering information for her 15th patient. First the frm_AS_Demographics is populated and saved. A button on frm_AS_Demographics labelled Basic Diagnostics will then open another form (for the patient #15) and then information is entered and saved.

I am attaching a simplified version of the .odb with unnecessary stuff taken off.

( 2019-10-14 18:31:54 +0200 )edit

Sort by » oldest newest most voted

Hello,

Based on additional but still somewhat limited information in the linked post, you have information in the record which should be split out into a separate table. That separate table would be one record per form and linked back to a specific record. You can have as many or as little # of forms as needed. This is part of 'normalization'. See-> What is Normalization? as just one of many posts explaining this.

Edit 2019-10-14:

There are numerous problems with the design of this database. For example, you cannot add a new BasicDiagnostics record for a patient until a History record is entered for that patient. The problem is that each table uses the PatientID as its' primary key. For the main table this is OK. For linked tables, each should have an auto increment ID for primary key and a second field for the PatientID with that linked to the master.

There are numerous other problems especially with unnecessary fields which should be placed in another table linked to the master (ie: different surgeries) in the Demographics table. In a separate table you can have as many or few entries as needed. There are many more problems too many to deal with here.

As for one form opening another, have attached a sample. Have inserted a new OpenBasicDiagnostics macro which opens the Basic Diagnostics with the viewed PatientID. If there is no current associated record a message is displayed (just demo - can remove). Have also set up second record on this form - PatientID #3 so you can see results other than one patient.

Sample --------PatientData.odb

more

Thank you @Ratslinger! Appreciate your help.

( 2019-10-15 00:53:00 +0200 )edit

As with all questions asked, as you have been helped, please help others to know the question has been answered by clicking on the ✔ in upper left area of answer which satisfied the question.

( 2019-10-15 01:17:56 +0200 )edit

Thank you much @Ratslinger! Appreciate your help in trying to help me.

( 2019-10-15 01:48:05 +0200 )edit

As you abruptly removed your last question, I can only guess you do not understand the answer/macro presented here in the sample. This can be used going from any form to another - even if it involves the same table/record. You simply need to modify the form name used and insure you have the proper data for the receiving forms filter.

( 2019-10-15 04:28:59 +0200 )edit

I would Bow to Ratslinger's expertise here, but my thinking would be create a master form with the critical data on it and then open other forms from there with related data. I hope you understand what I mean by Normalisation and Relations (i.e. loosely - grouping like data in one place so that changes are reflected throughout the entire database)

more