GetNthRecord HELP!

[Søren Dyhr]

Glad it did the trick, however a bit of advice ...you'll never stumble over two developers thinking identically and the graph you uploaded of your relations - reveals too little to be constructive to anyone else in a workgroup. If you collapse the boxes to show connections only and rudimentary info here and there are they tough to investigate.

What would have helped me would be a colouring scheme showing TO's stemming from the same table, to establish if you had any idea why Rays template works. It was obvious that you still didn't in this post where you posted this http://www.fmforums.com/forum/showpost.php?post/202799/ ...where Rays template gets into terra nullius is that he avoids lengthy scripting and tampering with the clipboard, there is nothing new in either multilinekeys or GTRR's in selfjoins when portalizing found sets.

But the way the found sets are made by simple searches, instead of multicriteria relationships where one of the legs are a strainer list of omitted as a multilinekey - is a matter of organizing the data. I paid attention to this:

My app opens with all calls (FollowUps) in the found set. We then wind up working with these calls most of the day. It is rather cumbersome to try to find and go to a specific record when you have 30 - 50 records in your found set

...and it made me think of the temporay nature Rays approach are designed to handle... aren't you're forced to make new searches each morning to make a found set to work on?? My point is such matters could be done with multicriteria relations and ValueListItems( so you aren't forced jump hoops around that selfjoin Rays template demands to work.

This template comes to mind:

http://www.newcenturydata.com/downloads/filter.zip

...where contacts requirering a call within a certain span of dates are listed in the portal, with the exception of the ones already contacted in yet another criteria/multilinekey using the unequal operator instead of storing such info in the clients record ...I say this out of personal preference, because I think Rays template is cute, but it's requirering you work around the selfjoin, which can be tough to document sufficiently ...so you after 1 years use suddenly needs to change something, is it not that easy if you have forgotten the trickery applied.

Another thing I noticed is that you use a plentora of fields in a pretty flat structure, you might get inspiration from this approach:

http://previews.filemakermagazine.com/videos/513/DataTagging_full.mov

--sd

[aldipalo]

Hi Soren:

Next time I will make sure my graphs are open so you can see my relationships.

Yes, In fact, everyday when a user signs in they will get their daily follows on screen. This is performed by a script that first identifies today's call backs and then once those calls are made gets those calls that have not been completed. Eventually I would like to add an EventRecord as shown by Matt Petrowsky so I can see who is doing what and when.

So far, regardless of the search the portal refreshes with the proper data and rather quickly. My contacts db is > 15,000 records and searches take approx. 1 second. But, your warning is something that should be heeded and I will attempt to properly document how it works so that, in the future, I will be able to remember what I did, providing Alzheimer's doesn't get me first.

I guess, because I showed you only those graphs related to the Portal Navigation layout and you couldn't look at the file itself you got the impression that my app is basically a flat file. On the contrary, I have 42 tables and two external databases employed. The screen you were looking at relates to 10 different tables. I just employed a lot of tabs because I don't like jumping from screen to screen.

If you note on the top of the screen layout I have two Buttons, "Company Filter" and "Contacts Filter" These employ New Centuries portal filter technique. I use this to quickly find a contact and Jump to a new screen in the event that someone calls in that is not in today's follow ups. I agree with you, it is a rather neat technique. I just couldn't figure out how to join the filter portal with the data screen. I played around with it, but honestly, couldn't get it to work and had no idea where I was going wrong. I think it would be a much stronger and more useful tool, but, I guess I'll have to work with Rays solution for now.

As I always enjoy learning new things and have found your references to such quite enlightening, I will view Matt's video that you so kindly gave me the link to, as soon as possible.

Thanks for all you help and direction.

Al

[Søren Dyhr]

On the contrary, I have 42 tables and two external databases employed.

And you havn't found the Anchor Buoy approach tempting??

--sd

[aldipalo]

Yes. I had a conversation with Kevin Frank about it. By the time I learned about it I was pretty well on the way to a complete mess. What I have done is as close to an Anchor Bouy version as I could get without dismantling all of my relationships and rebuilding. I think my graph is understandable, at least to me, and I can now at least find my relationships quickly and understand what I have done. I guess I should have done a lot more reading about FM before starting, but, that's how we learn, by our mistakes.

I showed Kevin my original graph and he asked for permission to use it as "What not to do"

I'm looking forward to his update to see how he changed it.

[Søren Dyhr]

I think my graph is understandable, at least to me, and I can now at least find my relationships quickly and understand what I have done

As long as you're aware that it's defeats the object of getting help, to some extend at least ...expecting someone to think exactly the same thing and roamed the same pastures is far fetched. Thinkgeeks are selling this T-shirt:

...intended to all us developers/programmers who had the occational enquiry from our family members, who're stucked in a certain dialogbox they can't make sense of. Since we make our living thru computers and technology have we definately seen all error messages

I've learned a new term in english today: obfuscated.... while having your problem fresh in my memory, when I pieced this answer together.

--sd

Edited April 25, 2006 by Guest

[aldipalo]

So, are you saying i am a Procedural Fanatic or an Objects Fanatic, because never the twain shall meet.

Actually, I'm neither. I have no formal programming education. Never took a course. Just tackled it on my own, bought some books and learned what I could. I have programmed in basic, DBase, developed apps in Approach, Access and now FM. I'm a novice at all of them. Perhaps when I retire, I'll take developing applications up as a living ( I love the challenge) and go take some formal courses.

Right now, I am very happy with the way my app is working for my business and have no illusions that it could have been done better and more elegantly. On the other hand for an old fart who's just looking to use the product at hand and make the best of it I don't think I've done so bad. But, as I said I'm old enough to know I don't have all the answers and every year I realize I have fewer and fewer.

But, please never stop pushing me or challenging me to learn more. I love it and appreciate your interest. For if you weren't interested you wouldn't do what you do on this forum.

Al

[Søren Dyhr]

So, are you saying i am a Procedural Fanatic or an Objects Fanatic, because never the twain shall meet.

Guess which cathegory the "tinkering" type usually lands in?? Who is it that falls in love with neat tricks and cute methods ignoring the "reach" ...because it get's the job at hand done??

Be carefull not to rely entirely on the knocks you gets. E.g. is there a algorithmic difference in how a cat and a dog running along a hedge, seeks a hole to get thru. The dog tries every glimse of light if it should be able to get thru thinking that enough physical strength would make it pass thru. But the cat calculates it's exit by measuring and by knowing what size would sufficient. Similar doesn't it attempt to knock it's environment into behaving...

--sd