Write conflicts

[cellboy]

I have a simple application for capturing online entries to an awards scheme.

It is based around gridlinker with a child grid that has an updateable detail part.

But whenever changes are made to a record I get an error message saying that another user is updating the fields with changes.

I have no idea what could be causing this, can anyone make a suggestion? It has to go live tomorrow and I'm starting to panic!!!

A sample of the application can be view on the following url:

http://nhmedia.alphafiveonline.com/HomeNH48s2Media.a5w

The structure is as follows
Gridlinker
Parent - Table of companies
Child - View comprising Table of Categories & Answers + Table of Questions

The gridlinker is filtered using the following expression
if eval_valid("pgrid.session.username") then
dbf.filter = "Company= " + quote(pgrid.session.username)
end if

Would this in anyway inhibit the updating process?

Any help would be really appreciated!

[Steve Wood]

I went to your site, but you must have changed your design because I don't find any grid linker or detail pages. Still have a problem?

[martin horzempa]

hi David

i was having the exact same problem
last week
try this
pack the table and then rebuild the indexes
it worked for me

hth
regards
martin

[cellboy]

Martin, I tried your suggestion. No change I'm afraid. Any field that is updated returns an error. (See attached jpeg)

Steve, the design is the same it just may not be apparent.
The company name at the head of the page is a single field grid that forms the parent (it is also the field on which the grid linker is filters so companies can't see each others' entries),

The list of categories below is the child grid, again just showing a few fields (category, deadline)

When the hyperlink is pressed, it opens a detail view of the child grid with question and answer fields visible.

[JerryBrightbill]

The error you are seeing in not actually an error, but a notification created by "Optimistic Record Locking". It indicates that the data on the server for that particular record changed after the page was created and sent to the client. Optimistic Record Locking saves a copy of the data on a page as it existed when the page was requested from the server. When you submit the page, that data is checked against the data now on the server. If they don't match, you get the message you see.

[cellboy]

That's all great, but how do I get rid of it because seeing those error messages leaves me feeling anything but optimistic! I really don't understand why the message is coming up. The dummy copy of the data in my page should not show any variances to that stored in the database, because no one else is able to access the underlying database stored at alphaonline. So why is this happening please?

[JerryBrightbill]

Without knowing how you have configured the layouts and the underlying data, there is really no way to determine why you are getting the conflict. However, for some reason the data on the server does not match the data that was retrieved when the page was requested.

Can you provide more detail on the actual configuration of the components in the construction and how the parent and child are linked? You mention that the child has a detail section. Normally, a child in a grid linker will only be a grid containing a single record, typically a columnar grid.

[cellboy]

The first item � the Company title - is based on a tabular grid component called CompanyParent, displaying just one field, company name. CompanyParent is based on an underlying table called MastCompany, which contains unique company names. CompanyParent is set to show 1 row only and has no new record rows, there is no navigation to prevent users viewing other companies� details.

The items in the list at the foot of the page are contained in a tabular grid component, CoCategories. CompanyParent is linked to this component by the field Company in a one to many relationship. The CoCategories component is based on a view of two tables: Co_Cats and Questions. (The relationship between these two tables is based on a field called Category, and is an inverted one to many link (ie value is unique in Questions).)

The detail view of CoCategories is updatedable and is linked on the category field. The grid table is hidden when the detail component is viewed, and vice versa.

I have chosen this arrangement because I thought it would guarantee security and prevent companies peeking at their rivals submissions. I don�t know much about using variables, but it was set up with a login page creating a session variable around the user name which then filtered the parent grid.

The bottom line is that only fields in the detail view are changed. No one else is accessing the database, and there is no possibility of the underlying record changing between the time it is called by the server and values are returned when the form is submitted again.

[cellboy]

I realise there is a lot to take in in that last post, but I would appreciate a steer. Seems to me this is another Alpha bug...

[Steve Wood]

I think its hard for 'us' to get our heads around it, even though you have explained it well. Its the sort of thing that if we actually had it in front of us, it might make sense. I keep thinking, I just would not do it this way. But I don't want to steer you away from your design.

I started down the path of a tabbed grid for a project, but opted for a design where each page was independant. You don't have to "link" the pages to secure them, or even to tie them together. You need to have a consistent filter method to isolate data.

If I were designing your application, I'd have an initial A5W page filtered by the customer ID. It would have a NAV component with links to the other pages. Those pages would also be filtered on the customer ID. That design may be off because I don't fully understand your app, but it seems to fit.

[Rich Roth]

I like your clean design approach.
The first page shows 3 award categories with deadline dates of 04/19/2006.
I clicked through each link to the submit page. There the date is shown in a different format: 19/04/2006.
I think the single field grid was a great idea.

[cellboy]

Thanks Rich, having more control over the design was one of the reasons I did it this way. The other was not knowing a lot about variables and filtering, I thought this would be an easy and bullet proof way of stopping companies peeking at each others' stuff. I'm told it's not a very good approach however, so I wouldn't copy it!

[Steve Wood]

Just to clarify, since I made the comment below, I don't know that it is or is not a good design. I have not looked at it in the Alpha enviroment. It's up to whoever is developing the application to work that out. It does seem convoluted, but I can't really tell. I mentioned that I had started down a path similar construction and bailed out in favor of what I described below. But I can't recall exactly why. Jerry and I spoke about it off line and think it is somehow "saving the record twice" during the same Submit, and that this might be causing the write error. But that is a cursory evalution at a distance, without benefit of the application in hand, and with hardly any time to spare!