Portal Sort issue

[vanderark1]

I have a portal showing LAST NAME, FIRST NAME

The relationship is dynamic in that the user can choose via clicking a button, to show only last names starting with A or B or C etc. They can also type in and see all names starting with JONES, SMITH (or any partial letters).

All of this works perfectly. However, the portal doesn't always sort correctly.

I have tried sorting at the relationship level (LAST NAME, FIRST NAME)

I tried sorting at the portal in the layout in the same way.

I've tried with both on or one or the other on.

Every time - it usually sorts. However, when I click in the portal, then click on the letter choices outside the portal, it sorts in record creation order (FM default).

Refreshing the window doesn't work.

I have checked to be sure the fields are correct (in the correct relationship), etc. Everything seems perfect. Just, sometimes, it doesn't sort as it's told to.

Non of the scripts triggered by user actions call any sorting into play.

I'm stumped - an ideas?

[comment]

Is your application patched up to 7.0v3?

[vanderark1]

Yes - I am using Developer 7.0v3

[comment]

Hmm. Some things worth checking/trying:

Fields are of type Text.

The language for sorting (in Storage options).

Spaces or unvisible characters in fields.

Rebuild the indexes for the sort fields.

Does it sort OK in the source table?

Edited February 24, 2006 by Guest

[vanderark1]

I am not sure how to rebuild the indexes, though I checked them and they appear correct.

Everything else checks out. It also sorts fine from at the source table.

It must be in my scripting, however - my scripts don't take any action on sorting that I can see. The scripts set globals that are used to filter the portal.

Running a sfilter cript sorts it incorrectly - immediately running it again sorts it correctly. I've tried COMMIT RECORD steps, refreshes, etc.

I'll keep troubleshooting. Are you aware of any sort issues after they patched 7.0v2?

[comment]

Can you post a sample file?

[vanderark1]

OK - sorry for the delay - I needed to pull out all the graphics, etc to get the size down.

The attached looks strange (no graphics) but the problem is visible.

User is: Admin

No password

Portal lists all names in alpha order (as per relationship and portal sort)

Click a name down the list - that name appears on right of portal, but doesn't move in the portal. This would be highlighted if graphics were still there.

Now click ALL button. Portal is sorted by creation date - not the sort I selected at relationship.

Click ALL button again - now it sorts.

Relationship is CONTACTS to HOME - as this is for navigation.

It must be a script issue, right?

Also - scripts refer to things that are gone - I deleted to get the file smaller. But, the workings are the same - as is the issue.

Thanks in advance for any advice!

Test.zip

[vanderark1]

Also - the ALL button was one of many buttons in the real solution. You can click a letter and see just the names starting with the letter, etc.

I pulled all those off to shrink the file.

The sort messes up with any letter or ALL selected - if you select a record in the portal other than the first, then hit another button (ALL or any letter). It sorts wrong. Then, if you click the same button you just clicked - it sorts correctly.

[comment]

I cannot reproduce your problem here.

Wait - that was in v.8. I do see it in v.7.

Edited February 27, 2006 by Guest

[comment]

I really cannot take the time to analyze what your scripts and relationships are doing in detail. It seems to me your solution is way more complicated than it needs to be (but then I am looking only at a portion of it).

However, I think I found the culprit - it is a screen refesh issue (probably caused by cacading relationships somewhere). If you add a Commit Records[] step at the end of your Select_Row_Highlight script, it should work.

[vanderark1]

I appreciate you looking at this. The Commit Record step seems to work - I needed to adjust another couple steps elsewhere to make it work for the whole solution.

I agree it's complicated, but in the scope of the whole solution, which is very large, it seems to be the most compact I could make it and still have it work within the complete solution (with my average skills). Thanks!

Edited February 27, 2006 by Guest