Temp Table Methodology

[nick_jp]

Hi All,

Wondering if there are any "accepted methods" for implementing temporary tables. Not looking for any hand holding... but if there are some common practices or pittfalls I woulad appreciate the advice.

From what I've read it seems the easiest way is that once you've worked out your table structure.. to put in the same set of TO's again (called temp_) and use those... am I on the right track?

[LaRetta]

...am I on the right track?

What track would that be? For instance, I only use temp tables as intermediate import steps. What type of solution are you proposing and what would you use temp tables for and what do you even MEAN by temp tables?

A bit more of your vision of using temp tables will be necessary, I think. :smirk:

[Søren Dyhr]

What track would that be?

Indeed! ...as a fairly frequent poster nick_jp should you by now have learned, that it's next to imposible to answer questions where context and purpose deliberately are ignored ...indeed there are no stupid questions, but some of them are empty gestures!

What do you take us for? Practitioners of the Ancient Art of Reading Coffee Cups??

--sd

[LaRetta]

Not looking for any hand holding...

What we're saying, Nick, is 'thank you' for attempting to keep to the point. We also appreciate your willingness to do the work here and not expect to have all the answers handed to you. But we still need more information to properly assist.

Read coffee cups? That's a new one for me, Soren! Was that a translation issue? Regardless, I liked it; of course, I'm quite strange so ... :wink2:

[comment]

http://en.wikipedia.org/wiki/Tasseography

[aholtzapfel]

:wired: If only there was a way to read FM's coffee cup.

[LaRetta]

If only there was a way to read FM's coffee cup.

Oh funny! Well there is ... it always reads "slowwwwwwwwwwww."

Thank you, Michael! I've heard of reading tea leaves but never coffee cups! :smile2:

[bcooney]

I was thinking that I could start a market for product placements in my solutions. Put a Starbucks logo on that cup! Then, have many summary fields in Browse mode layouts... :)

[LaRetta]

I like it! Or, while it is drawing the summaries, another script could run a subliminal loop in the background with, 'Pay this Developer more ... pay this Developer more ... pay this ...'

Just think of the control we could have if we chose to take advantage of it! :borg:

[comment]

FM has a coffee cup? Or is it a Windows thing?

[LaRetta]

Oh, no, my error! We're talking about FMS and how Server displays a coffee cup like Pro and Developer displays the hour glass. It's a standing joke when Server backs up - it takes FOREVER! :laugh2:

[nick_jp]

Hahaha! I guess that was a pretty open shot there. Sorry, I was tired and I'd spent too long thinking about this.

I'm building a standard CRM solution. Usual stuff, hold your client data and let you track project items, issues, quotes and invoices. I've read a bit about how FM will lock a record if someone is accessing it, that includes child records of a parent that is being accessed.

So, to get around this and add a degree of "cancel-and-go-back-ability" to the system, I feel I should load data into temporary tables, let users edit it there and then copy back into the main table (with a flag in the original record that tracks if someone is editing... so other views are read only or something...). Thinking about this further and you'll need the child data there otherwise anything in a portal is going to not appear etc... ergo, my theory is that you'd need an entire seperate set of tables, mimicking the "real" tables, with the TO layout on the retlationship graph the same. It sounds like an awful lot of scripting - but - your trade off is that the data is more secure.

Now, clearly there is another approach where you use temporary tables for some transactions only.

What I'm asking, before I go off and spend 7,000 hours making all these scripts, is if what I'm proposing is

a) an unneccessary waste of time and effort. Nobody ever needs that level of robustness in a FMP Solution

a good idea, off you go

c) there is no "right" way to do things, stop asking open questions fool

d) you have the right idea, but having done this a couple of times I can tell you the design approach that works for me is

Sorry! If I'd posted properly in the first place I wouldn't have wasted your time and forced people to talk about hot drinks.

I'm a big fan of tea, though its mostly green over here.

Edited November 8, 2007 by Guest

[LaRetta]

Hey, Nick! I enjoy your humor! But to answer your question, I vote a)

There is absolutely no way of handling record locking better than FM. I have read the horror stories of breaks using these types of systems. I vote strongly ... don't do it ... let FM handle it.

People have tried and failed? No, people have tried and died.

[aholtzapfel]

:twocents: I almost agree with LaRetta, I would not use temp tables to do it (didn't I see an example of someone using Globals to hold data for data entry.) Filemaker does handle record locking very, very, well and only in heavily scripted solutions with many users using the same sets of data have I ever had problems, even then the problems are few and far between and are related to not capturing the record locking errors well enough in the scripting.

I vote e) use temp storage for data entry of new records only, and better error capturing in scripting to check if record is locked.

But again, if the solution is not using a large amount of scripting and users are unlikly to be using the same sets of data at the same time, it is very unlikly to ever be an issue.

[Søren Dyhr]

Ah! I watched the .pps from Todd Geist's session at Devcon without attending:

http://www.geistinteractive.com/2007/08/07/transaction-demo-devcon-2007/

It is so, that the way I appoach devcon's, is a little pennywise but poundfoolish ... the problem is if you attend from loctions far from the spot where it's kept, can't you afford being in the wrong sessionroom too many times until the ROI is down the drains.

"Developer" is usually interpreted larger than the actual technicalities requiring ingnuity, there are elements from a Bazar as well, where people are eager to mingle with the right "types", so you can easily stuble over a sessions requirements are non technical, eventhough the sessiontitle misleadingly says so.

I believe it takes some pratice to read these things that goes with saying? However can I see that I could have used to attend Todd's session, if I just had made it to Orlando this year.

The transaction model has just lately been facilitated properly within the tool. But the slides talk about when scripting are interrupted by wonky network connections and similar. The reason why it as model is considered against a recusive structure in filemaker lives with the way unstored fields freshens ... and that it apparently scales badly.

So if you scenario is way beyond the mom and pop shops size, could these new facilities be utilized ... the .pps and the files in the mentioned download are pretty well commented in my humble opinion, eventhough I'm left back with the feeling that I should have made the economic sacrifice and attended.

So I can only suggest you poke deeply into his files, if the transaction model has any bearing on your task at hand ... but do not expect us to guess this was your aim with the casually tossed green tea leaves!

--sd

[FestiveEmbalmer]

I think you are referring to a Viewing Table?

There is some good stuff in the White Paper for FM Novices about it.

It seems like a more robust transaction model, but I am definitely not speaking from experience or with any authority in that regard.

[Søren Dyhr]

If only there was a way to read FM's coffee cup

I came to think of this, when listening to a radio program on buying advice to christmas presents.

There are at least two ways to understand you remark, either is it just joking about server backup or it's the fortune telling as such you're aiming at??

If it's the later wearing a slight of messianic belief on future absolution for chosen flock, could the question be.... should filemaker strive to fullfill certain groups of developers specific desires or should they persue a more open-ended strategy by adding layers of permutations posible to the tool and then let the users themselves deside what kind of hoops they wish the tool to jump thru.

My point here is that it's wrong to dance to demand of tecnology, it's similar to buy a toy (what initiated this reply) to a child wich exhibit a closed mythological discourse vs. a set of basic Legos and let the child independently deside from time to time in what direction the development/play should go.

I kind of attempted to make the same point's in this thread:

http://www.fmforums.com/forum/showtopic.php?tid/190712

Somehow did my lingual inadequacies prevent getting the message thu in that thread! For example do I find this downright stupid:

http://www.filemaker.com/ltc_interview/09-22-2007

...but it's probably the way people are misguided away from mathematical aestetics and abstractions, into eager attempts to make results right away, it does once and a while strike a culture, take for example the minoic art's doodling in every posible corner to simply just to show off craftmanship. A good way of descripting this shopkeeper'ish behaviour is this:

Actions are not chosen for their intrinsic merits, but for their instrumental properties, viz. their capacity to achieve other objectives.

From: http://www.chass.utoronto.ca/~jheath/

--sd