ennoying things...

[Saucepan]

got a small problem with some lines of code...

im extracting info from a repeating feild, seperating the indivudual entries with a " | ". the thing is that when inserting the info into the designated field i always starts of with the " | ", and i need it not to...

this is the code:

setvariable[$$i; count(people::names)]

setvariable[$$k; $$i]

loop

setvariable[$$i; people::names[$$k]]

setvariable[$l; $l &"| " & $$j]

exit loop if [$$i=$$k]

setvariable[$$k; $$k +1]

end loop

setfield[target_field;$l]

what i get out of thins is; "|craig|leanne|jody" and so on. help med get rid of the first " | " infront of craig...

[Søren Dyhr]

Try:

setfield[target_field;MiddleWords ( $l ; 1 ; 99999999 )]

In the last line of your script!

--sd

[Razumovsky]

How about a different approach? Create a valuelist of all related People::Names.

Substitute(valuelistItems(get(filename); "RelatedPeople"); "¶"; "|")

If you need to stick with a loop script for some reason, this would be more efficient:

setvariable[$k; 1]

loop

exit loop if [$k>count(people::names)]

set field [Target_field; Target_field&case($k>1;"|")&people::names[$k]]

setvariable[$k; $k +1]

end loop

Also, your use of repeating fields does not seem like the best choice here, and will likely cause a fair amount of additional work down the line. You should consider creating a People table and having them as individual related records instead of stored in a repeating field.

Cheers,

-Raz

Edited July 10, 2006 by Guest
fixed possible endless loop

[IdealData]

At the end of your script try

SetField[target_field;Right (target_field, Length (target_field) - 1)

This takes all the characters to right, except the first.

[Søren Dyhr]

You should consider creating a People table and having them as individual related records instead of stored in a repeating field.

Thanks for taking turn here, I'm almost exhausted!!! Neither will he consider that his use of Count( copes badly with omitted slots in the repeater....

--sd

[Razumovsky]

I'm almost exhausted!!!

That would be a first.

Neither will he consider that his use of Count( copes badly with omitted slots in the repeater...

Good catch! Yes, you would have to go by the total number of repetitions (blank or not), or condense the list first.

Just ditch the repeating fields, it will be much easier...

[Saucepan]

thanks idealdata, it worked like a charm

i like repeatingfields since they seem to save lots of space, compared to using tables (at least in the sims i´ve run on it). since the entries in the repeating field is going to differ quite alot from time to time, i find that it saves space to just have all the possible entries in a diffrent table and extracting just the small piece of info i need, instead of breaking open a hole new table...

i guess its the programming c++ background that forces me to think about this... all the time...

Edited July 11, 2006 by Guest

[Søren Dyhr]

i find that it saves space to just have all the possible entries in a diffrent table and extracting just the small piece of info i need, instead of breaking open a hole new table...

But how space saving is it to have the same thing stored in more than one place ...relational principles is to ensure that nothing get's in need for updating. Scripting in databases isn't about moving stuff to new places, but instead fidling with the key values to bring in a collection of fields storing atomic data called record. Your understanding of a record vs. object is wrong for a RDBMS!

The First Normal Form

The first normal form (1NF) requires that, in a given table, the data type of each field must not change from record to record. In C++ parlance, a database table must be like an array of structures; the data structure does not vary from element to element in the array. A database table must not be like an array of unions, in which the data structure can vary from element to element.

Each column must have a unique name. Each field in each record must contain a single value, meaning it must describe a single attribute and cannot contain a compound data type that holds more than one attribute.

There can be no repeating fields. A record cannot contain any repeating data, such as multiple fields in the record that contain the same type of attribute. (This would be a one-to-many relationship and should be represented in two tables.)

Each record must be unique; there can be no duplicate records in the table. Creating a primary key for the table (such as a Social Security number for people, a part number for products, and so on) usually ensures the uniqueness of records in a table. The primary key cannot contain a NULL in any records.

Snipped from: http://www4.dogus.edu.tr/bim/bil_kay/prog_dil/c++/ch07.htm

Your way of thinking in object oriented terms might better be fulfilled by using tools like this:

http://www.intersystems.com/cache/technology/demonstration/index.html

Instead of turning Filemaker out of it's realm!

--sd

[Razumovsky]

Saucepan,

Soren is spot on, but I thought you might also appreciate a more practical interpertation of what he is getting at:

I am not sure you should be that concerned with saving space - FM can handle 8 tetrabytes now. I doubt you will ever get even remotely close to that limit. I would be curious on the specifics of your size sims, but really what you are concerned about is performance, correct? Your experience has led you to believe that less size=more performance. This is not really the case. Size does impact performance, but design plays a much greater role. With repeating fields, you as the developer often have to work 10 times as hard to get the desired result. This often translates to Filemaker having to work 10 times as hard as well.

Keep in mind that this a general rant. I do not know the specifics of your file, and repeating fields might indeed be fine - it would just probably not be taking the most advantage of the performance filemaker can offer.

[Saucepan]

all i know is that with a structure thats fairly large (as this is) its optimal to save space in the idea that you dont create anything unless you´re gonna use it right away. otherwise you´ll just have lots and lots of "dead threads" to calculate, ti entries you dont use, but have to sort and match anyhow on your way to the entries you really want... this might be something filemaker automaticly screens against, (if so i didnt know) but most of the time is something you have to consider when structuring your program (c++ talking). this taken into effect a hole table would (logicly) create tons of unused info, especially if the entries vary alot...

anyhow, i might be completely off, this is just the way of the coder...

[Razumovsky]

This is the same size vs. performance issue. If you define performance as measured by file size, of course you are correct. However it would be good to gauge performance by how the file actually responds to user interaction, not against a vague penchance for parsimony (which I definitely can relate to).

Filemaker does not calculate for relationships that do not exist or are not valid. In fact, I don't think Filemaker calculates much of anything for relationships, only calculation fields really calculate in that sense. I do not think it is too broad to say that from a performance standpoint, relationships are the most speedy, economical, and powerful way to handle most 'calculations' of this nature if paired with good design.

Just some things to keep in mind.

*still curious about the numbers in your sims - what was the size difference, and total sizes we are talking about here?

[Saucepan]

as in response to the size differens i just simply created a number of databases, some with alot of tables with a small number of entries in each table, others with a small number of tables and a large number of entries per table. the ones with a larger number of tables where larger in size (just a few kb but anyhow...).

i know this is a very VERY dry way of simulating size, but i just wanted to test my theory, and thereby get a small understanding of what i was dealing with... i might just have been coinsidental but hey...

[Søren Dyhr]

his taken into effect a hole table would (logicly) create tons of unused info, especially if the entries vary alot...

Why is it a table defintion creates a lot of unused data, strictly speaking isn't data the same as information, if we speak C++ is the header file's constructor method and destructor method a ton of unused info, if no objects exists ...hardly!!!

I think we better think up an example, where each structure is measured in bytes against each other ...my guess is that field level validations and autoenter options doesn't take particulare more storage to make work than scripting if it not even is opposite.

Say a portal it has a sortorder to make a few records which are related go straight to the top of the view, where you opposed to that have to make either a script or a recursive CF that stuffs to the availiable slot in the top of a repeater. This is a build in function in the application when speaking of a portal, which you have to code from scratch since there is no enheritance to borrow from.

All your dealings are not tailored the same way the portal sort algorithm have been honed on ever since it's introduction with fm3, it simply purpose build, and if you are going to make something similar is it going to be made scripting steps which are interpreted one by one, guess which are the fastest??

--sd

[Saucepan]

apperently filemaker does more work than i give it credit for, i just figured you would have to optimize the structure yourself in order to make it run smoothly. keep in mind that im new to filemaker, the only databases ive dealt with prior to this are small ones that i basicly had to build myself using java and c++... guess thats why i havent really gotten the flow of thing quite yet.

i promise i´ll to try to quit using repeaters, it just looks so darn convienient... ???

[Razumovsky]

i just figured you would have to optimize the structure yourself in order to make it run smoothly.

You do have to optimize yourself- that is what we are all suggesting by getting rid of the repeating fields. You also need to consider and constrain the found set each relationship branch points to, or processing could explode exponentially. There are still plenty of other optimization issues you should be considering with relationships as well.

i promise i´ll to try to quit using repeaters, it just looks so darn convienient

I think Soren is working on a patch and some gum to help you with this- coming soon to your local pharmacy.

That is the best and perhaps only reason to use them, it is a quick and dirty way for the developer to pretend that their structure has greater relational depth without putting in the time to truly flesh it out. Kind of like relational spackle in a sense - will make that crack in your wall look smooth for the moment, but has little structural integrity.

Do not get me wrong here, spackle comes in very handy and has plenty of uses, but it is a poor substitute when cement is what is really called for.

I am actually having a bit of a summer romance with repeating fields - they can do some really nifty things and can be quite powerful when used in certain contexts. The scenario you describe does not seem like one of these contexts.

[Saucepan]

but if you put cement in your walls it will probably crack when it dries since cement expands when it hardens. try using tarmack, thats what i have on my walls, smells great!

joking aside, what would you recommend as a sub for the repeating fields, portals that go get thier values from clever tables? :P

Edited July 14, 2006 by Guest

[Razumovsky]

Well,

keep in mind that the only thing I know about your situation is that you want to count(people::names). Not a lot of background to go on here, but I can spin a short yarn:

You want to count some names. These names have something to do with people. These people have something to do with your solution. There are other things in your solution than that one record that these names have something to do with (or why else would you be crawling around with a candle in the corner of repeaters at this time in the evening?). If you put these names in a different related table occurence, you could sit back on your peoples couch, look through the relationship to names, look through any relationship from there to other people, names, weather patterns, samba troupes, and now the world wide web, all without spilling your beer.

That is what your repeaters are a sub for.