Jump to content
Salesforce and other SMB Solutions are coming soon. ×

Saving Record


lenosane
 Share

Recommended Posts

In LayoutSetup i´ve unchecked the "Save record changes automatically" option.But when i click out any field, filemaker shows me a dialog asking me if i want to Save,Don´t Save or Cancel the record...

But i don´t want my solution doing this i want to create a button called "Save" that saves records changes when i click on it,is it possible?Anyone have a better idea?

 

Sorry for my english,

Thanks

Link to comment
Share on other sites

  • 5 months later...

Lenosane - did you ever get this solved or found a solution to this problem of saving records? I have a client that after switching records upon making new/or editing records, the files are not being saved automatically. Several people in their network are having the same problem. Thanks. Leo

Link to comment
Share on other sites

Lenosane - did you ever get this solved or found a solution to this problem of saving records? I have a client that after switching records upon making new/or editing records, the files are not being saved automatically. Several people in their network are having the same problem. Thanks. Leo

 

I created a button called Save and make a script that have one line "Commit Records/Requests[No Dialog]. This button saves the record smiley-wink

 

But if i uncheck the "Save record changes automatically" option and click out any field, filemaker still shows me a dialog asking me if i want to Save,Don´t Save or Cancel the record...

Link to comment
Share on other sites

twiddledum,

 

record saving should be automatic unless the option is unchecked, and then a warning message should appear. a possible cause of records seemingly not being saved is that the user thinks he is in browse mode, while in fact he is in find mode. the difference is quite subtle to the casual observer.

 

that is why solutions should be built so, that at any one time it is clear to users what the context of a screen is - browse or find. Filemaker is very open in this respect, and a power user will not normally have trouble recognizing what and how, but as soon as you develop for others, it starts to pay off to start closing all the various entry points of filemaker's many functions - and start developing for specific procedures, so only one mode of finding a record (by your procedure), one mode of creating a new record (by your procedure), one mode of creating a monthly report (you get the drift)...smiley_cool

 

maarten

 

PS I found that a good way of testing your solution for robustness is giving it to test to your least computer savvy user. My bet is he will have hit on various snags within fifteen minutes after starting (I should know. I've been down that road. Oh Really! ).

Link to comment
Share on other sites

Continuing the issue of the user and interface issues. Its clear to the developer how it works, and a computer savvy person can figure it out on their own pretty quickly, but the computer illiterate presents a huge obstacle.

 

I would like comments on this theory. Is there better way or direction then where I am heading. Somebody has to have been down this path before and might know of a trap I am heading towards which I can't see yet. I am a newbee to FM of sorts with prior programming background from 15 years ago.

 

Single table with one classification field with a status of "want" or "have" (note there is another table called preferences to allows the user to control various layouts where they land when entering the runtime, etc. This project is being designed to eventually be distributed as a runtime to the general public.) Picture two basic layouts that are slightly different between I want this item and I have this item. The difference being at the point you know you want am item not all data is available that you would enter at the point of acquisition. So the want layout has less fields then the have layout. Which creates it's own set of problems if you need fields for a have classification that you do not want empty and you are in the want classification new record layout.

 

A field named title that must be unique to all records.

Several fields are not allowed to be empty which all show up in the have layout, but not in the want layout.

 

The issue of the user in browse mode and being allowed to edit the fields, has caused problems by the untrained user over writing data thinking they were creating a new record, even if the layout has a large button that says add new record. Auto save and the dialogs FM throws up automatically if fields are empty, etc if you move off that record can confuses people. Clicking outside any field etc. FM provides a multitude of options of how individual fields and individual layouts are handled.

 

The road I am headed down at this point is prevent field entry in browse mode to prevent editing the wrong record or changing a the title field so it is no longer unique. Add an additional button to my current Add and Delete record buttons. For sake of discussion lets talk new record creation only. When the user clicks on add new record, they get a new window, with a layout that has only one blank field for the title in a pause/resume Script indefinitely scheme. Remember I want this field to be unique to all records, want or have. Buttons at the bottom are cancel and or enter. No other navigation provided on this layout. The field for title is a global field to hold the input. Not the actual title field. Its value is cleared by the script that loads this new window so the user gets a blank field. Remember I want to control the validation dialogs not use the default ones provided by FM

 

Cancel closes the window. Enter performs another script which goes to a new layout for the user to finishing filling in the balance of the fields once that input has been checked and is unique. Again with two buttons Cancel which deletes to new record created with the desire to return the user back to where they were in browse mode. A Save record button that does the various field validation and I can control the dialogs and the events that occur as a result of user interaction based on those dialogs in a much more intuitive way that FM provides is my desire.

 

This is where the comparison issue in my single table has an issue. I can perform a find to compare the input gtitle field to title field of all records to determine if the new title input is unique. If it is not unique, then I don't want the user to point and click not in the title field and fill the rest of the fields like FM allows and then come back to the title field and add that info only to find they wasted their time because the entry in the title field is not unique. The problem of doing a find on the single table is when the user ends back in browse mode instead of being able to navigate to the previous or next record, I have to refind all the records that are classified as either wish or have for the appropriate layout before they land their again.

 

Granted using 500 plus test records, this all happens in a blink of an eye. The refind to the classifications of want or have, is just like is required when the user changes between the want or have layouts to split the classifications.

 

Does this scheme of trying to control the unique record and placing the user on different layouts for editing a record or adding a new record, make sense?

 

Should the comparison of the uniqueness of the title field be handled the way I explained? Or should there be a related table that just holds the title data for comparison as to not disrupt the current sort and find when the user falls back into the original layout that started the process. Granted for editing a record, I don't see this as an issue yet. That is unless the user changed the title field and it is no longer unique. I have not got to that issue yet in my notes and minimal design testing. But when they add a record to either the classification want or have, I need to make them land on the last record, so they see what they just input. Which in my limited testing is occurring as in the script it sets the field status to either have or want, based on the user clicking on add a new want item or add a new have item.

 

Sorry it is long winded to explain the concept. But is the scheme sound or am I heading down a blind alley? Which way of determining the uniqueness of the new record which I would check again on the final save would be best. My find method or a related table that contains just the info from the title field in addition to the unique record ID. As purely an FYI a typical user would have around 1,000 to 2,000 records with most being in the have classification over time and the want classification operates as a pre holding of data prior to purchase.

 

Thanks in advance for any comments or suggestions. Again I am a newbee. But as a result of my current profession wear fire proof underwear that can withstand critical flames if I am a thousand miles off on a tangent I shouldn't be going down and by understanding FM better wouldn't even consider.

Link to comment
Share on other sites

Question: would all this complexity be unnecessary if FileMaker behaved like Word or Excel or Photoshop, i.e., you do whatever you want but it's not saved until you deliberately Save it?

 

If so, put global fields on the layout. Values that are input into global fields vaporize when the user exits, and/or can be blanked before going to the layout to once again do data entry. When your user hits "Save", that's when you make a new record and then you use a series of Set Field script steps to populate the (regular, non-global) fields with the global field values.

Link to comment
Share on other sites

I don't know why there is an issue with this. According to my client, after doing a search for a record in a database of almost 3,000+ records, once the search shows the record in the "find results" window, usually they just start entering the new or editing info directly into the "find results" window fields. After they are done, and go into the normal "browse all" records window, they continue about their business and go into another database to pull the recently recorded info up. Now sometimes it won't appear right away, unless "sometimes" they quit FM and restart or close the DB and reopen.

 

So - you are saying there is a difference between entering or editing fields in a "find results" mode compared to a "browse" mode? They never had this problem before. Although they have upgraded from 6 to 8.5 recently, and the entire database interface was redesigned. Now, it's still on the same server, still be server as the "host" on the server that everyone else shares. They each have their own FM 8.5 program. There is no FM Server, just a hosted shared application that everyone else [about 3-4 people] access. They have done it this way for over 10 years and never had any problems.

 

Someone in another forum said is was "REALLY BAD" not to use a FM Server, with a dedicated computer for FM. Really? They went through an elaborate explanation as to why, and all the points seem good an valid. But my question is, why hasn't this particular system experienced any of those fatal problems they outlined?

 

Other than not saving a record when leaving a field or record automatically now, it was all working fine before.

 

Hmmmm.

Link to comment
Share on other sites

Someone in another forum said is was "REALLY BAD" not to use a FM Server, with a dedicated computer for FM. Really? They went through an elaborate explanation as to why, and all the points seem good an valid. But my question is, why hasn't this particular system experienced any of those fatal problems they outlined?

 

It's like smoking in a room full of asbestos particles and coal dust while a nearby incinerator burns vinyl. You can do it and not get emphysema or lung cancer (yet). Some people can do it and not get emphysema or lung cancer (ever). But the odds say it's a really bad idea.

 

You don't necessarily need FileMaker Server if you've only got a few concurrent users, but you do need a dedicated server (with file sharing turned off, no indexing, no antivirus, no automated backups, and unnecessary services & processes turned off).

 

If you don't use a dedicated server: that's you, or, rather, your database, puffing away on that ciggie and inhaling all those other contaminants. Odds are you're going to get file cancer.

 

File cancer is sneaky, you won't know you've got it until things quit working as they should, by which point your last known good backup may be 4 years old and all the changes to layouts, scripts, relationship defs, and whatnot are WAY out of date and you get to do them all over again.

 

Sufficiently good reason?

Link to comment
Share on other sites

grichter,

 

further to ahunter's advice, if you are worried about the interface, and if you are developing for, as you say, the general public, find a pool of prospect users (or some folks you just happen to know) and make a test version. Sit yourself down behind them and take notes as they move about the solution. If you see them making a mistake, don't react unless they end up in a dead end, then reset stuff for them and have them try again. then you'll learn quickly how your interface can be improved. also, there are useability guidelines out there. and books on interface design. I can recommend "Designing Interfaces" by Jennifer Tidwell (thanks to Ender for the tip).

Link to comment
Share on other sites

Question: would all this complexity be unnecessary if FileMaker behaved like Word or Excel or Photoshop, i.e., you do whatever you want but it's not saved until you deliberately Save it?

 

If so, put global fields on the layout. Values that are input into global fields vaporize when the user exits, and/or can be blanked before going to the layout to once again do data entry. When your user hits "Save", that's when you make a new record and then you use a series of Set Field script steps to populate the (regular, non-global) fields with the global field values.

 

To make sure I understand your concept and your comment "Save, that's when you make the new record". Are you suggesting a series of gfields within the same table. Or gfields in a different table and at the point of save move from the gtable to the main table?

 

I have been using just one within the same table to make sure I got the title field to be a unique value so I was in control of the validation and dialog box on error of validation failure. I considered adding gfields for the rest of the inputs. That was the reason post. To make sure I wasn't going down a blind alley.

 

Thanks

Link to comment
Share on other sites

grichter,

 

further to ahunter's advice, if you are worried about the interface, and if you are developing for, as you say, the general public, find a pool of prospect users (or some folks you just happen to know) and make a test version. Sit yourself down behind them and take notes as they move about the solution. If you see them making a mistake, don't react unless they end up in a dead end, then reset stuff for them and have them try again. then you'll learn quickly how your interface can be improved. also, there are useability guidelines out there. and books on interface design. I can recommend "Designing Interfaces" by Jennifer Tidwell (thanks to Ender for the tip).

 

Very sound advise and that is exactly what I did. Let one person use what I had so far that was very computer illiterate. Me knowing how FM works could deal with FM barking at me on validation failure. They couldn't, which lead to wanting to redesign the interface to be extremely user friendly and more simple for the user. We use the same concept in designing instructions sheets for our products at work. Give them to the person that doesn't know which end of a screw driver to use and stand back and watch and take notes.

Link to comment
Share on other sites

 

So - you are saying there is a difference between entering or editing fields in a "find results" mode compared to a "browse" mode? .

 

No. I am saying that to do a check for an unique record using a script that enters find mode, sets the field to check for a duplicate, performs the find, and based on get (foundcount) > 0 you do X and elseif get (foundcount) = 0 do Y, you can bring the records found down to 1 in the case the input was not unique. I need to return to either a want or have layout depending where I started (that part is simple) and have that layout in browse mode show all records if the layout is for the records that are classified as "have" only allow browsing within those. I am doing a second find before I enter that specific have layout look for all records whose status="have". Might be the only way to do it. But I was asking if there might be a different way then where I was headed.

Link to comment
Share on other sites

To make sure I understand your concept and your comment "Save, that's when you make the new record". Are you suggesting a series of gfields within the same table. Or gfields in a different table and at the point of save move from the gtable to the main table?

 

Makes no difference which. Global fields can be in the same table or a different table, but either way "saving" consists of making a new record and setting the local fields to the corresponding globals fields.

 

 

I have been using just one within the same table to make sure I got the title field to be a unique value so I was in control of the validation and dialog box on error of validation failure. I considered adding gfields for the rest of the inputs. That was the reason post. To make sure I wasn't going down a blind alley.

 

Thanks

 

I've done it before for customers who wanted "no record created until all the values have been entered" or "I need to be able to save or cancel without saving" types of behavior. It's an illusion but an effective one.

Link to comment
Share on other sites

This thread is quite old. Please start a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share



×
×
  • Create New...

Important Information

Terms of Use