Multiplying relationship

[genevieve charbon]

Hi,

I've 2 (possibly n) languages.

For each languages I've 3 possibly n' wordd to translate

That's an example to illustrate the point, do not think about the best way to do translations please.

I want to display to the translator the following portal.

French Word 1 Translation?

French Word 2 Translation?

French Word 3 Translation?

Dutch Word 1 Translation?

Dutch Word 2 Translation?

Dutch Word 3 Translation?

the "Translation?" field is where the translator would put the translation.

I've 4 table

The "main table" one upon which the portal will be displayed

The "Language tables"containing

language id / language name

so that's

1 French

2 dutch

a table containing the "words" to translate

1 Word 1 english spelling

2 Word 2 english spelling

3 Word 3 english spelling

and finally the "translation table" containing

language id / Word id / translation

The translator starts with portal listing all the lanhguege and the words to translate, all he has to do is to fill the translation field.

That means that, by defaut, the portal contains all the following rows

French Word 1 ?

French Word 2 ?

French Word 3 ?

Dutch Word 1 ?

Dutch Word 2 ?

Dutch Word 3 ?

So I need a relationship scheme that basically multiplies the languages by the word to translate

For one language I Know how to do it, but I didn't lanage to get to work for serval languages.

I tried

main table key X language id X word id

and some multikeys

but all I got is just 3 lines with the 3 words.

it's as if Filemaker knowing that in the word tables there's only 3 records, insists to display only 3 lines.

Thanks for your help.

[comment]

Did you mean something like this?

TranslateWords.fp7.zip

[genevieve charbon]

Thanks a lot, but not exactly.

First I need a portal and not a list

and in your example you have some words and 4 languages

I want the portal to display all the possibilities

so if I have 4 original words (original words are all in english)

the portal will display at the verys start

4 languages X 4 Words = 16 lines

what I need is a portal that displays all the possibilities of the combination of two tables.

in you solution, the main view is based on the Original words. This can't work for me, because that means you can only have a number of row equal to the number of original words.

Lets forget about languages for a sec

let's say I've 3 diiferent car paint color, that can be applied to any car

so i've one table listing the cars, and one table for paint color

in my paint colr table I have

blue

red

yellow

in my cars table I HAVE

Prius

mustang

I want a portal showing

Prius Blue

Prius Red

Prius Yellow

Mustang Blue

Mustang Red

Mustang Yellow

on the rhird column iof that portal we can imagine the operator would put the number of car ordered in that color.

I need the portal to display all combination possible from the get got, because as my operator is dumb, he would forget a car/color combiantion if he had to select it himself.

Is it more clear ?

Thanks

[comment]

A list view can be turned into a portal view quite simply by defining another relationship to the TO upon which the list view is based.

A list/portal will NEVER show 16 rows, unless there ARE at least 16 records in the table from which records are shown. Therefore, in your example of "4 languages X 4 Words = 16 lines" you would need first to create 16 'dummy' records in a join table between Languages and Words, and use that table as a 'grid' against which actual records are created (similar to the way my example uses the OriginalWords table as a grid against which the TranlatedWords records are created).

If all this is only to facilitate data entry by a "dumb operator", I would probably use some kind of 4 rows x 4 columns arrangement. Although this could be achieved by having 4 side-by-side portals to the same table, I think I would prefer having the operator enter the data into a repeating field, with two repeating calculation fields supplying the column/row labels (or a single field for just the row labels, if you prefer a single column display). Then, after the operator is done with data entry, I would import the repeating field into individual records in the target table.

All of these solutions require some maintenance when the number of possibilities is changed. For example, in the 'grid' solution a script would initialize the join table every time a record in one of the two tables forming the grid is added/deleted.

---

P.S. It is very annoying to spend time and effort answering a question, only to find out that "oh, but that was just an example - my real situation is actually different". I suppose you're not selling cars in different colors either, so this is once again a theoretical exercise, which may fit your real needs or not. Please be more considerate towards other forum members in the future.

[genevieve charbon]

Dear comment,

this is not theorical excercise. It fits perfectly my actual need, but I tried to simplified my example the most, because the reality is many time more complex so both examples are the same thing and fits my reality

And in the very first post I warned

"That's an example to illustrate the point, do not think about the best way to do translations please."

Anyway, your contibution was of a tremendous help, and now I'll have to use a dummy table. But that's annoying.

Thanks.

[comment]

I tried to simplified my example the most, because the reality is many time more complex so both examples are the same thing and fits my reality

But you didn't simplify your real situation - you invented another one, which you thought was similar. Obviously it wasn't, since my demo fits your first example, but not your second one.

The fact is that your two examples are fundamentally different. In your first example, there are only three entities: OriginalWords, Languages and TranslatedWords. True, you mentioned a fourth "main" table - but you said nothing about the relationship of this table to TranslatedWords, so it looked like you meant a viewer table used only "to display to the translator the following portal".

In your second example, there MUST be four entities - although you again describe only three: Cars, Colors and QuantitiesOrdered. However, such structure will be totally useless without a fourth table of Orders, to which QuantitiesOrdered must be related.

In your first example, you said: "The translator starts with portal listing all the lanhguege and the words to translate, all he has to do is to fill the translation field." So that once all the words have been translated into all languages, there is nothing for the translator to do, except wait for more words to be added to the OriginalWords table.

In your second example, the translator keeps translating the same words into the same languages over and over - and the translation of the same word into the same language may be different every time.

If you think we are too limited to understand your real problem, no matter how simplified, why bother asking for our advice? I am glad you found my reply useful, but I did not enjoy this experience at all and next time I will think twice before answering another question of yours.

[genevieve charbon]

But you didn't simplify your real situation - you invented another one, which you thought was similar. Obviously it wasn't, since my demo fits your first example, but not your second one.

The translated word is the same thing has ordered quantities.

but you said nothing about the relationship of this table to Translated Words, so it looked like you meant a viewer table used only "to display to the translator the following portal".

Yes that's true, just for display

In your second example, there MUST be four entities - although you again describe only three: Cars, Colors and Quantities Ordered. However, such structure will be totally useless without a fourth table of Orders, to which Quantities Ordered must be related.

Again, that's an example, I don't care if there's orders to relate to.

The problem is that you want to do my whole solution, you want to address the bug picture. I'm just asking can that technical part be done in FMP ? Yes/No/How that's just I ask.

Frankly, if someone would post "please create my solution" I would found that very bold. So my solution is my business (I mean it's up to me to create it), I just need to know some technical bits.

I know that you took way to much efforts to create a solution. That's terribly nice, but I'd never expected someone to actually build a file for me like that. So many thanks, but I didn't meant to ask you to do it.

If you think we are too limited to understand your real problem, no matter how simplified, why bother asking for our advice?

I don't think that your too limited to, but what I know, is that explaining the whole thing would take way too much time and way to much text (that I'd expect someone to read) when all I want to know is if FMP can do that technical bit.

The problem here, in that forum, is that people are too nice, and that's counter productive.

It's as if I'd ask, can filemaker put something in the clipboard (don't reply I know the answer), and then the forum would respond.

Why do you want to cut and paste, you can do that, etc.

Cutinad and pasting in not ideal for your solution, what is you solution about.

No, I just want to know if fmp can copy/paste. That's all.

I had to quit servoy development because I spent weeks in the forum because I asked if I could get a fmp like unstored calculation. Rather than replying "no you can't", people deluges me with workarounds (that never worked), insisting that servoy could do it while it couldn't etc..

So I've quit Servoy because in 3 weeks I had nothing worthwhile done, while I created my first fmp solution in 2 weeks.

So sorry to have bothered you, but I never wanted anyone to spend more than the time needed to read my first post.

And finally if I explained you all my solution, then you would have spend a lot more time to grasp it, and argue how I should do it in a more pro, efficient way, forcing me to reconsider the whole solution.

I don't use filemaker for the beauty of database design, I prefer a quick mess that works, than something that takes weeks to produce something but which is technically brilliant.

So if my simple question leads to bad design, that's my problem, fact is that I'd either not understand or take too much time to create something as nice as you'd do.

And finally, I think all those work around we are teaching each other are very bad, because it led Filemaker inc rest on glaring omissions and let us, the kiddies to play to try to compensate.

That was exactly the same thing in servoy forums. rather than all dev to lady canine with me to servoy inc to get a decent import/export function. They all created countless very narrowed focused import / exports solutions that can only serve their limited purpose. Moreover they spent each days to recreate something that should have been in 1.0.

The result ? Servoy is in 3.5 and can't import/export as well as fmp.

If all dev would I've bitched them to death since 1.0 rather than playing in their sandbox, in 1.1 an import function would have been made. And then nobody ever would have lost precious time to recreate it.

But I'm guessing it's to create a plug-in business.

Look at the relationship graph in FMP. It's horribly inefficient. So after maybe 3 years we still can't have a list of table occurrence to jump directly to them, we can't search the main table of them.

It would take an intern one week to fix that, and give the fmp community a graph that's not a major pain in the as.

Rather than bitching against that, great FMP developers prides themselves to develop techniques to sort things out. Squid etc.

Some, few, get paid for that.

But all those takes a lo of time to do, a worthless time because it's time spend to deal with a flawed/incomplete implementation.

You have to be able to recognize lacking implementation, and then ask ask ask again and again to have this fixed.

Look at the iPhone. Steve said : stylus are crap, tiny keyboards arte crap. Let's invent the next big thing. The FMP community, the Servoy community, and all the forums on earth are the same. They act like Palm, trying to workaround inefficiency, they're resistant to change.

So I deeply think the Filemaker community is responsible for the crappy filemaker we have today.

The guy who invented horizontal portal workaround is praised, while all he managed to do is to let Filemaker Inc ignore that obvious feature. If something is too vocal with it, just point the guy to that crappy workaround.

The ones who say that filemaker can be used other the WAN, while it's slow to death at it, just let FMInc to ignorer that issue.

The one who are saying that FMS requires a powerful (because FM inc did tell them) server with nothing on it rather than fmp, just lead countless people wasting money on spanking new hardware while the cpu usage never uses more that 30% (if you're lucky) because it's so inefficient with networking.

Those people just helped FMinc to rest on its laurel once again, and I could go on and on.

Now you're certainly thinking I must be burnt, but please think again, take a deep breath, and you'll see that there's a lot of truth here.

Edited December 11, 2007 by Guest
Many typos

[comment]

The problem is that you want to do my whole solution

No I don't. I also don't like people telling me what I want. I believe I am an expert on that at least. The real problem is that you misrepresented your situation.

that's an example, I don't care if there's orders to relate to.

But I do. You may think it's not relevant to your question, but it is. The fact is that I changed my answer once I realized that. You cannot judge what's irrelevant, when you don't know the answer.

I am not suggesting you need to present every detail of your solution. And almost every post omits some relevant details, so follow-up questions are required. That's perfectly understandable. What I am saying is that you shouldn't invent an entirely imaginary situation in order to present your problem. That almost never works. Nobody's that good as to invent a perfect parallel, so inevitably it to comes to what I said before: "Oh, but it's different in my case." Or, to quote you verbatim: "Thanks a lot, but not exactly."

The rest of your post doesn't seem to be related to the topic, so forgive me if I don't address it here.

[LaRetta]

WOW. What a long post when a simple, "I'd rather do it myself would have worked as well." Are you related to me per chance (I'm known for long posts which say little)?

Genevieve, there is some real truth to what you say .... people here on Forums (and obviously servoy) are sometimes 'way too nice' for their own good. Instead of simply saying, "thank you" for the information and deciding not to take it, you climbed aboard a righteous horse. I read a sign once, I'll bet you know it which said, "People say I have a bad attitude. Those people are STUPID."

In future, begin your posts with what you expect such as "I want only a YES or NO answer. My examples are fabricated so keep your opinions and demos to yourself because I will not appreciate them anyway."

Then we ALL will be happy because those who wish to respond can and the rest of us can help those who truly appreciate it and want to learn. It may surprise you, but there are thousands of us who dearly appreciate the help Comment, and others like him, provide us. I assure you that, if your posts are clear about what you expect from us then you will get exactly what you wish. :wink2:

[Vaughan]

"... people here on Forums... are sometimes 'way too nice' for their own good."

Heh heh, you should see the PM's I've sent over the years, some of those definitely haven't been nice.

My public posts usually get edited heavily before being sent. Gotta keep up appearances!

[The Shadow]

Look at the relationship graph in FMP. It's horribly inefficient. So after maybe 3 years we still can't have a list of table occurrence to jump directly to them, we can't search the main table of them.

It would take an intern one week to fix that, and give the fmp community a graph that's not a major pain in the as.

I'm sure FileMaker would love to hire that intern, please forward his resume to FileMaker's HR department. :

Seriously, the issue is more complex than it appears. Hopefully alternative methods for moving in the graph will appear soon.

There is currently type-ahead on the table names from within the relationship graph, I think that was added in 8.0 or 8.5; that's awfully similar to type-ahead in a flat-list, imo.

The ones who say that filemaker can be used other the WAN, while it's slow to death at it, just let FMInc to ignorer that issue.

I don't think FileMaker is ignoring the issue, and major strides in a positive direction were made with FMP 7. The issue is really that the entire FileMaker design is not your standard client/server setup, the FileMaker client is very smart, and the server is rather dumb. Again, that's been improved in more recent releases, previous to FMP 7, the server did not even have the ability to run calculations.

Also, I agree with Comment, you'll need dummy records to make the portal have the full "16" rows.

[Søren Dyhr]

I don't use filemaker for the beauty of database design, I prefer a quick mess that works, than something that takes weeks to produce something but which is technically brilliant.

So if my simple question leads to bad design, that's my problem, fact is that I'd either not understand or take too much time to create something as nice as you'd do.

And finally, I think all those work around we are teaching each other are very bad, because it led Filemaker inc rest on glaring omissions and let us, the kiddies to play to try to compensate.

Perhaps surprisingly? - I agree with this, but Filemaker intrinsically are one of the best tools around at all to facilitate your hesitating way of development.

It's certainly not crappy because it's utterly forgiving say for a lack of blueprint ...but to expect filemaker let you do something exceptional without a substantial measure of exercise and practice, is pure and simple a misunderstanding of what the tool is about. Honestly is Ernest Koe hits it right on the spot:

http://www.proofgroup.com/articles/2006/jun/filemakery_part_i

Then do you get it wrong, the "way" you think you get better by these forums - do never ever ask questions to your own solutions via the forums, you should instead let yourself being drilled skill-wise by ... replying and think up possible solutions to other participants problems, as well as nitpicking on their reasonings as they present them!

You are absolutely right, when you get a solution thrown - with no questions asked, is it usually in the category "Cute and Clever" ... which is highly circumstantial if they would work at all, they are utterly useless until you have found the realm and reach in them, which boils down to, it's not what kind of hoops the tool might hop thru in it self, but what kind of hoops you would be able to jump thru armed with the tool given enough drilling.

--sd

[LaRetta]

You are absolutely right, when you get a solution thrown - with no questions asked, is it usually in the category "Cute and Clever" ... which is highly circumstantial if they would work at all...

I hope you aren't implying in the least that Comment's demo is cute and clever. Although always clever, I would never term his work cute; nor that he 'throws solutions no questions asked' at people. In fact, his solutions are usually (no - always) spot on if the person is at all clear on what they need.

He provided a specific demo which answered specific questions by someone who shouldn't have asked the questions if they didn't want the answers. This is a forum of providing answers and, in fact, your statements imply most of us throw cute and clever around with no concern whether it helps someone or not. I disagree with you and I disagree with genevieve.

BTW, this demo he provided is very good indeed; to let it slide by simply because you both have twisted ideas of learning is really sad. But then, *I* learned from it anyway.

Edited December 11, 2007 by Guest

[comment]

I would never term his work cute

Aw, shucks. Another dream shattered...

[Søren Dyhr]

I think you know what kind of solutions I mean, the shopkeeper'ish ones... where proper cross interrogations deliberately are ignored.

Engineered solutions requires the opposite .... questioning almost everything which are believed to be true.

I'm certainly not accusing Comments contributions here for being worked properly thru, but instead the notion that something is universally applicable ... the questioner should always be asked about purpose and context, if it ever so slightly makes any doubt. We have the good fortune that Michael always feels the tiniest ripples.

But I'm also aware that the questioner hardly ever can use the advice right away, but have to digest the implications before using the suggestion ... there is a tendency to believe that it all matters about tiny quick fixes. But it's usually an entire mindset which needs to get allocated!!!

--sd

[Genx]

Just to weigh in ... because really, what would a thread be without my opinion LOL - probly good, anywho: The question you provide will logically determine the answer you get.

A very vague question will never receive an answer that the person submitting is hoping for, likewise a question that isn't the question the person submitting wants to ask will get the answer to that question, and not the question that they actually want the answer to .

We are not asking you to fully disclose your situation and frankly, for what its worth, I don't think anyone really cares - we all have our own issues and projects to deal with. That aside, unless your whole project relies on this one item, you should be able to clearly seperate your explanation of this item from the rest of your system - that or throw together a sample file illustrating your problem.

Finally, I always love sample files, and they were some of the most helpful things especially when I was starting out - nothing beats a good sample file and I always appreciated anything that anyone took the time to throw together to help me out.

[Søren Dyhr]

We are not asking you to fully disclose your situation and frankly, for what its worth, I don't think anyone really cares

But often times is the introduction missing, and you're supposed to jump in abruptly with a quick fix, as if we knew all tricks of the trade. What seems to be the problem with this description is that a phantom was set up nowhere near the key issues!

With sample files is it so that it's only when you don't need them they start to make sence! Talmud have an expression somewhere:

"Who made water, dunno but certainly not the fish"

--sd

[LaRetta]

Soren, Alex ... yes, there is a fine balance between providing too much, not providing enough, asking a question not pertaining to the problem or expecting someone to do your work for you. But there is clear expectation that, if you ask a question on a forum, you will 1) possibly be asked further questions, 2) possibly get a demo and 3) may receive suggestions on a better way of doing something. The postee can then simply choose NOT do it that way; to then post a full-page rant about not wanting to be given what was given, is ridiculous.

Personally, I like to see tolerance for those who don't provide enough information; tolerance for those who provide too much (like me); appreciation for those who take time to respond even if it doesn't fit one's need; and most importantly, respect for someone who has taken the time to think through a GOOD response and even provide a demo. For God's sakes, these Developers charge top money for what they hand us for free. Anything less than respect for their efforts totally irks me.

I would never term his work cute

Well, Michael, one of your calculations was laminated and placed on my wall, if that counts as cute!

LaRetta

[Søren Dyhr]

Hardly anyone can pride themselves with a notion of thinking absolutely by straight lines, it does then have to be non lingual worn ... Because every language known to mankind provide it's own quirks simply because it's a hybrid of thousand's and thousand's individual contributions. These discourses are near impossible to snap out of, because your identity is carried by it as well.

This means you can't underestimate the actual work performed by the subconsciousness - when a solution is given to you as a template do yourself the favor and occupy your mind with some small talk far away from the problems at hand, or take the dog for a walk.

I experience it at every rock'n'roll gig ...that the first set have it's flaws, but when the musicians go to the first break - something happens, their minds have somewhat adjusted to the environment and the hyper complexity provided due to the distractions the pause provides, by not being on stage for the half hour such a break takes. Even before making the adjustments in monitor levels required in the break, everything sounds much better in the second set.

--sd

[genevieve charbon]

> Shadow

There is currently type-ahead on the table names from within the relationship graph, I think that was added in 8.0 or 8.5; that's awfully similar to type-ahead in a flat-list, imo.

I know about it, it suffers the same problem than ever with FM. It works perfectly on a limited scale. it's as if FMinc never imagine about larger scale project.

Let's say I've a customer table. Logically I've named it

"customers" because I'm a non programmer. If I'm a programmer I would name it CUST_

Over the time, I will get a "customers to invoice", "customer to address", "customers to yadayada" etc. relationships.

Let's say I've 10 of those.

So many relationship will start with customers

So with type ahead which only works with a limited number of characters (or limited time to type, and in fact both) will make me potentially jump through the graph 10 times (fortunately with command-G, I don't have to retype it)

With a list however that would be almost instantaneous.

an intern could do that menu in 2 days.

A more clever dev could implement a FMP 9 like scriptmaker box with a search box in one week

Yes, that's true, heck, I've almost done in in applescript before bumping on FMP key ahead number chat limit and total lack of UI scriptability (which is a shame in itself)

I don't think FileMaker is ignoring the issue, and major strides in a positive direction were made with FMP 7.

Yes, that's true there's progress but still too slow. But we're in 9, and still not decent while the problem exists since at least server 5.5 (the days I started). But I was just mentioning this to point out that even in those 5.5 /6 days there were people pretending it was doable, there were even fmp hosting companies, and during that days you were pointed buy fmp documentation to better hardware etc. All was lies, and still is.

On the performance issue itself, FMS 9, drum roll, allows server side script processing. Great.

BUT, you can't do import exports ! Ok, so that's useless in most situation as most of time consuming scripts will deal with import / export.

Yes I know that's because they're not web savvy scripts. WHO CARES. I'm talking about 100% scripted, no dialog import / export scripts. So there's no reason, beside that perhaps those script steps are flagged web forbidden because they may require dialog boxes and that nobody in FMinc though about it and left it that way.

In fact FMS 9 server side is a joke (not to say a scam) because it's just scheduled scripts only. So that's the same, in fact less (minus web non savvy thing), than a client on the same machine than the server with a cron triggering some scripts.

And yes, to get scripts done the fastest, YOU HAVE to have the client on the same machine than the server contrary to what every experts and FMP inc tells (that's because fmp network is so chatty it slows downs everything)

I tested it (Single FMP Client with the file no server takes 100s, FMP Client on the same machine as server 127.0.0.1 200s, Client server over network.

Server side scrip processing means to me that at least, you can tell the server to execute a script from inside a script, at least, or more intelligently, that the server does all the scripts the client fires itself and just pass it the result.

Calling "server side processing" a cron job is a scam.

Edited December 11, 2007 by Guest

[Søren Dyhr]

Over the time, I will get a "customers to invoice", "customer to address", "customers to yadayada" etc. relationships.

Let's say I've 10 of those.

So many relationship will start with customers

But getting them could be reflected by the graphs organization, say anchor bouy'ish approaches.

you can't do import exports ! Ok, so that's useless in most situation as most of time consuming scripts will deal with import / export.

Isn't time consuming scripts an artifact of inappropriately structured solutions, and especially the need to import and export are really giving your style away. This is stumbling near to syncronization, which relational structure are there to prevent.

It's becoming clear that you have a headstrong willingness to mold every circumstance you encounter to you desires only, deliberately ignore that there actually exists methods to prevent all these cul de sac you have landed yourself in.

We have all been fooled to believe that the forgiveness of filemaker, perhaps by the strong marketing effords too, chanting the mantra "No Programming Required" ... most filemaker developers come from the media/entertainment industry, hardly any I have encountered comes into this tool, with a strong mathematical basis in set theory and predicate logic, upon which it all is based. This is why scripts and global fields are believed to be lifesavers when life gets complicated!

In short stop tinkering, and learn some proper approaches!

--sd

[Genx]

Not that I often openly defend FileMaker but...

I tested it (Single FMP Client with the file no server takes 100s, FMP Client on the same machine as server 127.0.0.1 200s, Client server over network.

That's called network latency,and i believe you are referring to ms not s. Now take a much more complex script that loops through 100,000 records, does various heavy duty calculations and let us know how long that takes.

Server side scrip processing means to me that at least, you can tell the server to execute a script from inside a script, at least, or more intelligently, that the server does all the scripts the client fires itself and just pass it the result.

The main advantage of these scripts is that they can indeed be run on a regular scheduled basis removing the need for a robot machine with an extra FM license - this is something a lot of us developers called for, for a long time.

Regarding the relationships graph - I suggest you use some other items of software before you go and start critisizing that graph - IMHO its one of the best features of FM. While i admit the improvements wouldn't go amiss, it is a very powerful tool and if you don't organize the graph properly its no ones fault but your own.

[genevieve charbon]

Isn't time consuming scripts an artifact of inappropriately structured solutions, and especially the need to import and export are really giving your style away. This is stumbling near to syncronization, which relational structure are there to prevent.

Well Soren, you make bold assumptions ! Fact is, you would also use the same import / exports as I do, in my situation.

Because my FMP solution is a front/end aggregator of 2 other databases, and there's no other solution than doing scheduled import and exports.

Moreover, Yes, I give my style away, I sometime have to import (and hence reproduce data from one table from another), for performances reasons ! I learnt it the hard way starting with a perfect no data duplication policy => slow solution.

And finally, FMP lacks SQL like tools, so yes, you have to use some temporary tables, and populate them with information from other tables.

But, data replication is a common practice in FMP world, just heard matt petrowsky suggesting it for someone, and the problem of this thread must be solved using some replication Multiplying relationship, the only solution is to create an extra table and populated it.

I was asking for an clean way of solving my problem in this thread, but there's none. So I'm listening the help of you math/logical expertise here.

How, imports are much faster then replace from related field by the way.

So yes import export are needed unfortunately, and badly

Finally, I don't care about my style. I'm perfectly happy with a mess that gets the job done, rather than a clean database that does half as my messy.

BECAUSE MY JOB IS NOT TO TIDY GRAPHS, or to develop FMP solutions. I'm a knowledge worker, you can call my style shitty, I don't care. FMP is a knowledge worker tool it's great, but I'm more in FMP customer target than FM pro developers.

In fact, FM pro devs, are in, the real world more the oddity that I am here.

That's not that I don't want to learn, but in fact many advice I get are theorical only, and fails in production (with decent speed), in fact In most of the case I've already tested the the theorical clean solution

So Soren, I'm listening to you. How do you do a solution which deal that 2 other database without import exports ? Where's the proper mathematical solution ? Because yes, my long script deals with that exclusively. Then there's some data processing.

An I have a lenghty script that creates a statistical database. Yes, in that solution I duplicated the same information, perhaps 10-20 times.

Yes before I used the relational only stuff, but navigating that was awfully slow. So Yes my solution weights 200MB when there's maybe 5Mb worth of data, but at least it's decently fast

Edited December 13, 2007 by Guest

[genevieve charbon]

That's called network latency

Hello ? of course I know about network latency. And that why you don't need a very fast machine for your server contrary to what FM best pratice says. Because FMP is so chatty that it shoot itself in both feet with network lantency.

Thats' why you true server side processing. True side processing means.

"How you are a client, and you want to do a script ?

Let me handle it for you" - says the server, I'm back with the results in a sec, I'll sent you the result !

That is what is properly called server side processing, and that is the worst falw of FMP its' not built that way and that's really inneficient

The main advantage of these scripts is that they can indeed be run on a regular scheduled basis removing the need for a robot machine with an extra FM license - this is something a lot of us developers called for, for a long time.

So what you saved 300$ on a extra licence but you paid a lot more to upgrade to FMS9 ? And guess what, you can't run all the script because all steps need to be web savvy.

That's a joke. You still need the robot machine. How, in fact you shouldn't use a different machine, use the same machine as the one that runs the server, that's the fastest way (cause network latency) contrary to what FM inc says and that all FMP experts repeats without actually trying it.

But you just agreed with me, you just said that FMS server side processing is the same as a robot machine sans licence (but again you're wrong because of web savyy script steps only)

So FM inc, only delivered a half assed, unusable IMHO, robot replacement. You, the FM dev community never asked for an half assed replacement but a full assed one.

You'll see my point when you'll actually try it

An calling robot replacement "server side processing" is a scam

I suggest you use some other items of software before you go and start critisizing that graph

Which, what items ?

IMHO its one of the best features of FM

I was overjoyed when I've seen it the first time, but FM did two mistakes. They scrapped the old relation list (Shadow explained the reasoning but that wouldn't preclude a simple list) without deeply considering the consequences.

Then, they didn't thought about scalability. Everything is brillant in Filmekaer when you have 2 tables with 10 field and 2 scripts. Then you get bigger…

if you don't organize the graph properly its no ones fault but your own.

You can sleep well, you pointed your finger, I'm a bad person, rejoice !

It's my fault if my graph is messy, yes, ans it's my problem. But it's FM fault to force us to have tidy graphs because of the lack of a simple feature an intern could do in one week.

When google launched Gmails, people were complaining, where are thge folder.

googles replies organizing folder is a waste of time for humans, we have powerfull search tools. And it works.

Computer are skilled for search, but not in the FMP world. That's a shame in 2007 !

Nobody would be forced to organise their relaionships if theres was a simple list and a seach box.

But, since those are lacking, everyone has to spend days to tidy their graph because FMP doesn't gives 500$ to and intern

and thats' a total shame.

[Genx]

But it's FM fault to force us to have tidy graphs because of the lack of a simple feature an intern could do in one week.

Why don't you go apply for a job at FMI?

In any case, I don't think anything constructive is going to come out of this continued "discussion". If you want to continue flaming FM - go start a more relevant thread.

Edited December 13, 2007 by Guest

[Ocean West]

:backtotopic:

lets agree to disagree and move on.

[genevieve charbon]

Thanks Ocean for your open mind

[Søren Dyhr]

How do you do a solution which deal that 2 other database without import exports ? Where's the proper mathematical solution ?

I relate the b*u*g*g*a*r*s, as simple as that! Never tagging...

Nobody would be forced to organise their relaionships if theres was a simple list and a seach box

As if competence and dedicated never could be needed ingredient ... If guts feelings only were to rule the world, take a look at the grap here:

http://www.anecdote.com.au/archives/2006/03/data_informatio.html

...read the reasoning behind it, your way of being Knowledgeworker isn't at all about knowledge, you could perhaps create information, but you collections are not put into any kind of sense making, you rush on producing even more information ...as if the world really needed more indigestible chunks of information, such as lifestyle suggestions, style and fasion advice.

The truth is you can't buy such matters, how dearly you ever would wish, it's sometimes called jack of all trades master of none.

--sd

Edited December 14, 2007 by Guest

[genevieve charbon]

b*u*g*g*a*r*s

This doesn't make any sense to me. Nor explain how do you do without import exports in a 3 database scenario

As for your philosophical consideration useless and aside of the point.

The situation is this one.

A. FMP as it is today : You are forced to makes your relation graph pretty, or then you'll never be able to find the relation you want quickly because FMP lacks an obvious simple tool

B. FMP as it could be after an intern week of work at FM Inc

with one simple list of all your table occurence. Fast access to your relation. Tidy your graph if you want to, don't if you don't want.

I don't see the point of sticking with A. That doesn't make sense to fight against a simple feature.

Soren I grant you the right not to use it if FMI eventually put it.

But I've an idea why you're insisting with A so much

That differentiate good and bad developers in your opinion. Good boys tidy their room, hence their graph, they feel it reassuring. Good for you you're a good boy.

More cynically that helps you to outline a difference with pro and non pro dev, and so that may help your business.

Hey customer, look at my graph, now that's something

customer : He sure does have nice graph, he's the man !

So Yes I'm a bad person, you'll go to heaven not me, good for you, but that's not a reason why FMP shouldn't do its homework and offer us a simple way to avoid 5 minutes fighting with a graph just because their design doesn't scale. Especially when it's so easy to implement.

And finally, I say that FMI refusal to put search boxes everywhere (in field list, value list, relationship graph) while at the very same time put a long overdue search box in scriptmaker windows with 9, is as shameful as a dev who would have coded an app in 1999 with a Y2K issue built-in.

But I do hope, that when FMP 10 will eventually put those search boxes, FMI will sell you a licence without all those pesky search tools just for you. So you'll still be able to pride yourself to develop the hard way.

I also Hope you'll post a terrible rant when those tools that can only help incompetent people and leave them in their incompetency will finally appear.

[genevieve charbon]

Here's a special Xmas present for Soren and all the "relation graph is a marvel of efficiency let's not touch it a bit" singers.

Here's my graph, 1511x950 pixel of pure shame and pure proof of incompetency.

Enjoy yourself, make a big printout of it, show it to your customers to explain them why they should hire a pro dev.

Pride yourself by looking at the difference between yours and this crap.

But bear in mind that even with that crap, and minus the hours you spent to tidy your graph, I could work as fast as you if FMI just provided a simple menu with all the table occurrence listed

And finally I've the best argument ever for my simple menu, if it had been there, I'd never have insulted the holy grail of the universe.

[Vaughan]

"But bear in mind that even with that crap, and minus the hours you spent to tidy your graph, I could work as fast as you if FMI just provided a simple menu with all the table occurrence listed"

Yes we know that Gen (may I call you Gen?). Of all the advances introduced in FMP 7.0 you'll get little argument that the loss of the relationship list is the most lamented, and there are many ways to improve it.

But we must work with the tools we have, and complaining about it in a forum achieves naught.

[genevieve charbon]

Yes we know that Gen (may I call you Gen?).

Sure, I just missed a heart attack because I've first read you called me Genx -)

you'll get little argument that the loss of the relationship list is the most lamented, and there are many ways to improve it

But we must work with the tools we have, and complaining about it in a forum achieves naught.

In days you're the only second to admit there's issue with the graph. Thanks for this grain of truth.

Well doing nothing won't help either. I count on the fact that people would see thye're not alone to think like that, and I hope it will generate more pressure on FMI.

I also hope every attendee to devcon wil lady canine FMI so much they'll release it.

It's been 8 /8.5 / 9 = 3 versions without that glaring omission fixed.

I say that every devs who ever talked to a FMI people are responsible for that. because they let FMI do it.

And finally, what I know is that Righteous conservative people who live their lives in forums trashing every newcomer with they pure truth denying style are hurting the platform a lot.

Maybe my hitching helps to identify them.

[LaRetta]

Well Soren, you make bold assumptions !

Look who's calling the kettle black!! Here are some of your blanket statements based upon misinformation, false beliefs and totally unproven statements. Good grief, how presumptuous you are - you don't know us at ALL:

• It would take an intern one week to fix that
  
• great FMP developers prides themselves to develop techniques to sort things out. Squid etc. Some, few, get paid for that.
  
• the Filemaker community is responsible for the crappy filemaker we have today
  
• Those people just helped FMinc to rest on its laurel once again
  
• an intern could do that menu in 2 days.
  
• A more clever dev could implement a FMP 9 like scriptmaker box with a search box in one week
  
• YOU HAVE to have the client on the same machine than the server contrary to what every experts and FMP inc tells
  
• I'm more in FMP customer target than FM pro developers.
  
• You'll see my point when you'll actually try it
  
• FM pro devs, are in, the real world more the oddity that I am here.
  
• contrary to what FM inc says and that all FMP experts repeats without actually trying it.
  
• because of the lack of a simple feature an intern could do in one week.
  
• FMP as it could be after an intern week of work at FM Inc
  
• I say that every devs who ever talked to a FMI people are responsible for that. because they let FMI do it.
  

And what you do (blowing hot unsubstantiated air) speaks so loud that what you say I can't hear. Anyone can throw statements out and say they are fact - I see no facts coming from you, only blanket statements which lump people into incorrect groups with no respect for the individuals. And the stronger you scream your stance, the less I believe you.

And finally, what I know is that Righteous conservative people who live their lives in forums trashing every newcomer with they pure truth denying style are hurting the platform a lot. Maybe my hitching helps to identify them.

All you've done is identify yourself very clearly in my book.

[genevieve charbon]

Laretta, all the bullets you highlighted are right, proves me that one is wrong for a change before wanting to put me in page of your book, like you're reproaching me I'm doing.

What I do, is that I dare to say what other don't, and I do dare for the sake of those who reads the forum in search of information.

those will save money not to buy a very fast machine for their server because it's worthless contrary to the red book's say

Those will see that the strange sorting beahviour, those will see they're not alone to think the relation graph is a mess.

Etc, etc.

Beside trying to categorize me, beside beign happy to bash me, all the soren, the genx and you just never replied with argument based on the nature of the facts I expose.

They all just atttack me.

Soren bold statement is " import/export" are for kiddies, if you use them, you're a moron". Yes that's bold.

The reality according to "you" is that

• FMS server has true server side processing

• 100% scripted non interactive import/export shouldn't be allowed on server side processing

• Relationship graph is a masterpiece of productivity

• FMInc was 100% right to remove the list (Shadow explained very nicely why they didn't put it, but IMHO they could have made a simple one less ambitious just table occurence names)

• it's perfectly logical that void is greater than a value, every human being thinks like that

• Please FM inc, don't listen a word from that bastard don't change a thing on this masterpiece of your, let us tidy graph with color boxes, that always impress customers

Edited December 14, 2007 by Guest

[genevieve charbon]

La Retta, that's not thinking instead of you, that's pure logic

I say this is crap, I get a deluge of of topic bad comments, no other devs (besides vaughan) dare to say there's some truth in what I say, but many forum enthusiast continue to bash me.

It safe to assume that those bashers are thinking that what I point as crap is gold to their eyes otherwise they wont bash me so much.

If they do think I'm not wrong, but continue to bash me because agreeing even partially with me is against the pravda, then I think that's even worse.

"You know more than all the engineers at FileMaker."

Not engineers, but certainly more than their managers/marketers. in fact you don't need to known, and sometime not knowing is best because you have a higher view of things.

But yes with my advises the company will have more trouble to charge for semi updates full prices because updates would be real ones.

Since you think I know less than fminc, you assume all is well, and we're safe protected by those geniuses

"You know more than all the Developers on this site."

No, not even a sec, but I 'm more honest than those who, just by zealotry are trying to hide truth but not replying to facts but prefers to bash me aside the fcats.

Nobody proved me I'm wrong to wish a rlationship graph with some kind of list of table ocurence, Nobody prouved me that FMS use really fast hardware (while I've provided timed benchmark proving the opposite)

"childish behaviou instead of fact"

yes that's you. Where are your facts. Mine I've exposed them.