Navigating in a Set v 10

[Tom Cone Jr]

Re: Navigating in a Set v 10

Jerry said:

Thanks. I guess I should have mentioned that this problem occurs in the browse view, not the form view.

Jerry, the behavior of the browse results from your set design. The column of Composers is misleading. There's really only one record in the primary table that contains "Rachmanioff" (sp?) You're trying to page down through the list as though there were 40 or 50 records all containing "Rachmaninoff". There aren't. What the column contains are virtual field values from each row's composite record.

Your problem goes away if you use a different set. Make Songs primary. Link one to one to Musicmen. An example is attached. Check Toms_Browse and Toms_set.

-- tom

[jerfilm]

Re: Navigating in a Set v 10

Thanks Gentlemen - I have it now. And two good ideas.

Jerry

[DaveM]

Re: Navigating in a Set v 10

While this may have nothing to do with your problem, change the linking field from numeric to character. Numeric fields should only be used for mathematical calculations. You can use numbers in a character field to link the tables. Try it and see if it helps.

With all due respect - I totally disagree. Character fields are made for letters. LOL Also, if you happen to switch to sql in the future, you will be using numeric as linking fields. Back a few years ago, I had a mess because I used character linking fields. That was several versions ago, but it shut me down for a week trying to figure out why the numbers I had in the char fields messed up. Numeric ever since and never a problem.

[jerfilm]

Re: Navigating in a Set v 10

One final question - using Tom's solution, making Songs the parent database, how to I get the list of compositions in alpha order by composer? I have tried sorting the Songs database by Id+Composition and it works fine within that database , but when you add that database to the set, they no longer are. (the early part of the list is alphabetical - they were entered that way. But once beyond the initial collection, the ID number no longer puts composer records in alphabetical order).

Jerry

[Ted Giles]

Re: Navigating in a Set v 10

Works as you want in the version I downloaded, but not the first time I opened the Form. That threw me a bit.
I created different indices as a try out, rebuilt the existing indexes and tried again and it worked.
Came out of Alpha - went back in and it was working fine.

[Tom Cone Jr]

Re: Navigating in a Set v 10

One final question - using Tom's solution, making Songs the parent database, how to I get the list of compositions in alpha order by composer?

Where do you need the list? There are different considerations depending upon whether you're talking about a form, a browse layout, or a report.

-- tom

ps. Usually best to ask different questions by starting a separate message thread. Makes searching much easier later on. This thread now contains at least 3 separate lines of discussion.

pps. FYI, in Alpha Four each DBF file was called a database. That's not true in Alpha Five. They're called tables. Collections of tables (and sets) make up a database.

[jerfilm]

Re: Navigating in a Set v 10

Sorry about the three topics. In this case, one thing led right into another and a new thread would mean explaining the whole damned thing over again.......

No, this is the Browse layout, exactly as you set it up, Tom. But the compositions won't aphabetize....

Jerry

[Tom Cone Jr]

Re: Navigating in a Set v 10

Jerry, because the browse is based on a set that uses two tables, linked one to one, you can easily sort the records on field values in either table.

Check this screencast:

http://screencast.com/t/gG50LUdqtE

[jerfilm]

Re: Navigating in a Set v 10

Bravo and thanks for the tutorial, Tom. It works perfectly as you said. I guess I didn't think of that solution, perhaps because when I was working the set using the Musicmen table as the parent, it didn't work. I'd go in and specify how I wanted it sorted and then nothing would happen. When I'd go back to look at what I'd done, it was blank.......

At any rate, I do much appreciate your patience with an old man and thanks again

Jerry

[forskare]

Re: Navigating in a Set v 10

With all due respect - I totally disagree. Character fields are made for letters.

Very True. However, when a number is used in a character field, Alpha reads it as a character. That's why there are functions to change the value to a numeric or date value. This has been a subject on several past versions and there are more who had problems by using a numeric field than those who used character fields. If there was a problem with a linking character field, it wasn't because numbers were used. I've been using Alpha since the early A4 days and have always used a character field with an 8 digit number as the linking field. Never, ever, did I have a problem with that.

Also, if you happen to switch to sql in the future, you will be using numeric as linking fields. Back a few years ago, I had a mess because I used character linking fields. That was several versions ago, but it shut me down for a week trying to figure out why the numbers I had in the char fields messed up. Numeric ever since and never a problem.

Alpha's definition of a character field is: The most common field type, Character allows any combination of alphanumeric characters. Maximum of 255 characters. I'm happy it works for you but I suspect your situation was due to another issue. I know there are others that use a numeric field as a linking field w/o problems but just as the 'Total' function will work on a form, I believe a numeric field is not meant to be used as a linking field. If one has a need to switch a database to sql, functions could be used to convert character to numeric.

[Ray in Capetown]

Re: Navigating in a Set v 10

Topic 1
I didn't see the problem described with Jerry's original database. As long as used with one to many design in mind. What's to be remembered is that;-
Doing manipulations of a child table of one to many - without being mindful of the over-riding control that the parent bears - could produce apparent anomalies.
The safest if you want to manipulate parent AND child independantly, is to work with a flat set construction (one to one) - or understand what the flattened view will look like - that gets back to the browse Jerry was using for one to many - the over-riding order/filter WILL be that of the parent. That is why Tom made that suggestion.
Topic 2
IMO using a numeric fields for linking is just plain silly. I dont program for SQL but I don't think it's logical.
Topic 3
Three excellent examples of progressive look-up dialogs from Mike and Tom for many to learn from (Mike actually provided two, take a look) and these kind of things are the gem of this board. Thanks.

[Al Buchholz]

Re: Navigating in a Set v 10

Topic 2
IMO using a numeric fields for linking is just plain silly. I dont program for SQL but I don't think it's logical.
.

Actually it's quite logical to use numeric fields for linking. It's just easier in a dbf/Alpha system to keep the link fields as character - because they be treated as a character field in the linkage process.

[Ted Giles]

Re: Navigating in a Set v 10

Maybe I'm off base here, but I use whatever is appropriate at the time as a linking field.
Example.
UK Social Security Numbers - AA NN NNNN C I'd treat as a Character field - well I have to.
Project Numbers - NN I'd treat as a Numeric.
Using the KISS principle, it might be that I have two or more links in different tables for display purposes using a Set. My version of Rationalisation I'm afraid.

[forskare]

Re: Navigating in a Set v 10

Project Numbers - NN I'd treat as a Numeric.

Why treat this as a numeric field? Just because they are all numbers? If that's your reasoning, it's not solid logic.

[Ted Giles]

Re: Navigating in a Set v 10

We all have our different ways of working Kenn.
What works for me I tend to stick with.
No reason not to use the numbers as characters, I agree, but it's my choice.