Jump to content
Claris Engage 2025 - March 25-26 Austin Texas ×

edit record returns blank field in value list


This topic is 8746 days old. Please don't post here. Open a new topic instead.

Recommended Posts

  • Newbies
Posted

I have a value list defined; I'm sharing my database over the network using web security with edit enabled and no field restrictions on the value list in question. When a remote user edits the value field, a blank field shows on the remote screen even though the change appears on the master database. The only way the change ever becomes visible on the remote screen is for the value list to be clicked upon in the master database manually. Validation is selected rather than AutoEnter. Anyone else ever experience this problem, have any ideas?:

Posted

What version of FMP are you using -- is it the latest patch level?

How is the value list defined -- custom or based on a field, or a related value list in FMP5?

If it's a value list based on a related field (FMP5) the bad news is that the don't work through Web Companion.

  • Newbies
Posted

Thank you for replying! I'm using FMP v. 4.1, and the value list is defined as custom, not related. Do you know of a patch for v. 4.1 that addresses this issue?

Posted

Sorry I don't think there is a problem with FileMaker Pro 4.1 a such (I've never encountered the problem).

The latest patch is 4.1v3 and Web Companion 4.1v6, make sure you are using the latest.

Can you explain what you mean by "remore screen" and "change appears on the master database."

Value lists by themselves are not much use... but when used to produce pop-up lists or menus or check boxes or radio buttons they are very useful indeed.

Are you web-sharing the databases through Web Companion, or are the remore users connecting through FileMaker Pro (if they are, make sure the server and client machines are running the latest patch level of FMP).

[This message has been edited by Vaughan (edited December 11, 2000).]

Posted

It sounds like there is a misunderstanding of how web access to the database differs from access through FMP clients.

When you view a database record on the web through Web Companion, the web page is generated at the moment the request is made (that is, the link that generated the page was clicked) and then the connection to the database is broken -- this is how all web pages work, it's not just a FMP thing. The web page can be considered a "snap-shot" of the db record at that time.

If the database record is subsequently edited or deleted, the web page won't automatically be updated to show the change, unless the original request is made again or if the browser's refresh/reload button is clicked.

I saw this because perhaps there isn't a problem at all. it's working the way it should but it's not meeting your expectations.

BTW are you using Instant web publishing or custom? (Custom is where you create the html format files yourself.)

  • Newbies
Posted

I dont think you understand the question I'm asking or the problem im having. The point is that you are supposed to be able to edit the record from a remote location. If, when you edit the record from the remote location, you cannot SEE the change that has been made to the database, then there really is no point in being able to edit the database through the web companion. You might as well just have the database just on one computer and have everyone come physically to that computer when they want to edit it. The fact that the web companion interface has an "edit record" function certainly suggests that the intent is for the editing to be real and visible to the user. So also does the advice in the help menu that says that if "Auto Enter" is selected, you will have the problem I've encountered, but if you have "Validation" selected, you wont. I appreciate your answering and trying to help, but it does no good to tell me that this is how it is supposed to work and that I simply have expectations the program isnt designed to meet. It clearly is NOT how it is supposed to work. Also, as I indicated in my last post, it DID work properly for one day, and then, without any other change having been initiated, it stopped working properly and has refused to work properly ever since. I am not imagining this, trust me. I have had several experts look at this and it is a real issue and it is as I have described it.

  • Newbies
Posted

I do understand that web access takes a "snapshot" of the database as it is at that moment. The problem which you dont seem to be getting, is that once you have done an "edit record" on that pop-up menu based on the value list, you CANNOT ever get a snapshot of the change that has been made to the database, no matter what you do, until someone physically goes and "clicks" on the field on the computer which houses the database. However, on that computer, the change made from the remote computer does appear as soon as the "edit record" request is received from the remote computer. The point is, that if the change has been made to the database, why, then, if we request the file again from the remote computer, do we not now get an updated "snapshot" of the file as it now exists? We dont, and we cannot. All we get is a blank field. That is NOT how this is supposed to work, trust me.

  • Newbies
Posted

By remote screen I mean the web companion screen that you see when you access the files I am sharing over the internet through web companion, from another computer. WHen you select "edit record" in that screen, and make the change to the pop-up menu defined by a value list, the change occurs in the database, but will not appear on that other screen until the pop-up menu field in the main database has been clicked manually. You can restart both machines from scratch, and the change will not show in that field on that remote screen until someone manually clicks on the field in the original database.

Obviously, the answer to your other question is that I am sharing the file over the internet through the web companion.

The most frustrating part of this is that for one day, this worked properly, when I changed the setting in the "field format" menu from "Auto Enter" to "Validation" with no particular validation option selected. I did this after reading in the help files that having "Auto Enter" selected there would cause this problem. It worked the first day I made this change, and has not worked right since, though I have gone back and rechecked all those settings many times.

Posted

Ken

After the record has been edited through the web interface, the web-user will have to re=display the page to see the change.

I assume that you are using custom web publishing (may be a bad assumption on my part though) and that the standard format files of record_detail.htm -> record_detail_reply.htm are used: record_detail has a form with the text boxes on it for all the fields; record_detail_reply is just a message that adviss that the record was edited correctly.

OK somebody has editied the record, got the reply page -- what then. If they click their browser's back button they don't see the updated record (or updated value list) they see what it looked like before the edit, because the broswer just drags the page up from it's local cache (Internet Explorer is a real demon for this wacky behaviour, it's tenacious with it's cache because the cached image loads faster). To see the updated page you'll need to refresh/reload the page. But even then that might not work as the ISP may have a cache that won't flush automatically.

There was a debate about this a month or so ago, Anatoli even reported a 10 minute lag on his system -- maybe you can verify this?

So is *that* the problem? The web page display doesn't update itself?

[This message has been edited by Vaughan (edited December 14, 2000).]

This topic is 8746 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.