browse column will not refresh

[cwtart]

I have a wizard generated NetWeb browse and form. The primary key is a single String(30) key and this field is displayed on the browse. The primary key field can be edited on the form. If I change the value of the primary key field in the form it will not refresh on the browse and the value displayed shows the original value. All of the other fields in the form that are displayed on the browse will refresh properly on the browse when the form is edited. The primary key field is being changed in the database but not refreshed on the browse so when I attempt to edit the same record again just after having changed the primary key field I get a record access error. If I refresh the entire browse by going to Last or First then the new value is displayed.

Using NT 8.31

[terryd]

Hi
Leaving aside the inadvisability of allowing primary keys to be changed, or even seen, by the user is your form a popup?
If it is then possibly you need to check the refresh whole browse after change box on the Browse form change tab

[cwtart]

Terry,

I am well aware of the inadvisability of changing primary keys - but in this instance it is not doable. This is a very old table in the database. Doing a refresh on the whole browse after edit is not a good solution because the edited record looses its highlight when the browse resets. I am hoping there is a way to refresh the primary key field after edit. Thanks for the response.

[terryd]

Yes I've been there ( with the old system allowing changes to the primary key) ;-)
I agree about the refresh whole browse problem. It seems to me refreshing the whole browse negates the benefit of popups from browses.
I would like to see rather a refresh the single browse record changed but I suspect that this is rather a lot of work on Bruce's side. As in my software changes that look simple to the user are not necessarily simple to the programmer.

[Bruce]

hi Chuck,

The changing of the primary key value is not something that is officially supported, although as you noted it does at least mostly work. Cascading that through to the browse though may be very difficult because the browse relies on a stored POSITION and by changing the primary key the old POSITION setting is useless.

In other words, there's no way to match the browse to the changed record, because the POSITION of the changed record is unknown.

So I'm not sure a solution to your problem is even possible.

What I would do in this case is attack the problem from a slightly different direction.
a) add a unique field, and key, to the table. (You can leave the Primary key, and field unchanged - just add another unique field to the table.) Personally I'd use a random string for this, but you can use an auto-number if you like.

b) change the browse and form to use this field as the "Unique Key" instead of the Primary key.

That way the Position key is not changing, and it should preserve the position ok.

cheers
Bruce

PS - remember the Unique key is for finding data, not sorting it, so your sorting on the browse should remain unchanged.


cheers
Bruce

[cwtart]

Bruce,

I think I will have to bite the bullet and create an auto numbered primary key for my table. The problem here is because this is PostgreSQL I cannot use SetIfNew = AutoNumber to let FM3 populate the new auto-numbered field - the FM3 docs says SetIfNew = AutoNumber does not work in SQL. All of my other tables that already have an auto-numbered primary key have a sequence set in Postgres so I will have to figure out how to create the SQL sequence for a table that is not be created but updated with a new field.

[Bruce]

Hi Chuck,

>> I think I will have to bite the bullet and create an auto numbered primary key for my table

While my opinion is certainly controversial in some quarters, I strongly feel that an auto-number is a bad way to do a primary key. A much simpler approach is to use a unique-string (called a UID or GUID) approach. This is faster, is less dependent on a specific backend, and allows your system to scale beyond a single database (which is really useful for exporting and importing data.)

that said, FM3 does support the adding of new Identity fields (ie server-side-autonumbers) in SQL. see
http://www.capesoft.com/docs/fm3/fm3.htm#duoAutoNumber

Cheers
Bruce