separate data and structure

[LVA]

I have a client that has a system in FM with separate data and structure.

I'm doing some changes in some of the files but there are some points that are getting me confused.

I would like to know the advantages and disadvantages of developing that way and would also like to ask some quastions.

The fields on the interface file are related fields and these related fields are lookup fields from another file. When I enter the interface file to update or insert any new information , these new informations don't save.

I guess I would have to change the structure because as the informations in the fields that are being viewed at the interface file come from a lookup field I guess this way I won't be able to update or change the data working on the interface file. Can someone help me with some ideas about how this could be changed ?

[Kundinger]

Hello Luiza;

First... It sounds like you may have 'inherited' someone elses solution. If so, you may have to 'interact' with the original developer to determine his/her design & security schema.

Second... I will give you some thoughts on separating data & structure...

- I typically create solutions that have a 'Main' file with all the 'interface' components. This file has multiple layouts that have portals to related files. The 'Main' file has all the 'automation' scripts to perform all automated user tasks.

- My typical solutions then have 'related' files that contain all the data. These files have a 'lock' layout just in case a user happens to try to open it or access it. These files have all the 'report' layouts for printing. These files also have the 'sub-scripts' that are 'called' from 'Main' file scripts.

- Most of the 'relations' within my typical solutions are setup as 'true' relations (not Lookups) and allow for creation and deletion of 'related' records in the appropriate file.

- I have a 'security' system as part of these solutions that requires user 'log-on' and user 'log-off'. This 'security' system prevents any client user from accessing the 'development' side of my solution. Not even the client management & ownership have 'development' access. That said... some client users have more privileges than other users. I do this through a series of 'prefs' files that contain user privileges.

- I use the phrase "typical solutions" to make it clear that I have situations where I have implemented 'exceptions'. I try to stay away from 'exceptions', but there are times I have no other option.

This type of system sounds like what you are dealing with. If so, you may need to determine the relationship that existed between the original developer and the client. Another words... does the client 'own' the solution... or does the client have a 'license' to use what the developer 'owns'? Example: You buy MS Word... You have a 'license' to use it... Microsoft 'owns' it. You therefore are NOT permitted to alter the original application.

I hope this helps!!!

Bob Kundinger

[gnarlydude]

Bob,

Can you recommend a good reference book or guide for doing this? I attended a session about this at the FMP DevCon in Palm Springs and this whole concept really appeals to me. I just don't know how to get started.

Thanks,

Joe

[Kundinger]

Hello Joe,

I have yet to find the 'definitive' book, article, video, or class on this particular subject. I have learned how to implement these ideas through 'trial & error'; reading various books & magazines; 'tearing apart' sample files; ETC. I have been using FileMaker for more than 13 years and a lot of my knowledge comes from experience. I do pickup most FMP books... more, because I am a 'bookstore junkie'. I use these more for reference. 'Scriptology' is a 'great' reference and has great sample file to 'tear apart'. FMP training is 'iffy'... I have attended 'good' & 'bad' classes. Every instructor has an 'agenda'... some are good teachers... other, NOT!

One source of 'great' information is this 'FMForum'. It has a good deal of knowledge 'boucing' around from the people who encounter 'snags' and overcome them. I typically 'invest' an hour a day reading various 'posts'. I will then spend another hour or so trying to create a solution to some unique problem. I consider some problems a 'challenge' and work to solve it... this is how you learn FMP... trial & error.

I specifically recommend the 11 areas of the FMForum's 'FileMaker Functions & Features' sections and the first 4 areas of the FMForum's 'Brain Food' section. The 'posts' in these areas share a wealth of information and give insight into how other people approach the same problems. It's great to see how other people 'think outside the box'.

I hope this helps!!!

Bob Kundinger

I see that you are from Minnesota... where? I live in Bismarck, ND and do most of my work in eastern ND & NW MN.

[gnarlydude]

Thanks for the reply Bob.

I live in Park Rapids (north central) which is where I graduated high school. I grew up in Grand Forks though and spend much of my younger years hunting Devils Lake area.

You say you do most of your work in NW MN? Thats a long drive from Bismark!

Joe

[keshalyi]

Ugh... as a Northerner myself (SW Wisconsin, though) I can say without a doubt, that EVERYTHING is a long drive from Bismark .

I will say it is important to closely examine the advantages and disadvantages of the seperate data structure. I've worked with people who swear by it, say they would never program any other way. But frankly, a lot of stuff I've done just doesn't call for it, and in many cases just makes it unneccesarily complicated.

The important thing, though, is documentation, particularly with seperated structures, in my limited experience. Integrated DBs are easier, they just sit there and are very naked and honest once you start to poke aroud their structure. With a seperated structure, I'll reiterate, your best bet is to go to the owrds of the original developer. If you can't? Before you get your hands in, make yourself a chart of every table, every relatinoship, etc. in the whole darned thing, and hang it somewhere prominent. God knows how many times I've tried to do something on someone elses toy, and just totally biffed the memory of how its built. Remember where everything points, and wwhat makes it point to hat it points to. And frankly, if you don't need it, and its not doing you good, my advice is ditch the structure. ITs a tool, not a showpiece. Just my 2 cents though

[gnarlydude]

My biggest reason for pursuing this is that I really like the idea of doing away with the export/import hassle every time I do a version update to a solution. If the data is separated from the structure (user interface) it's my understanding that I can just slap a new interface (and functionality) over the data layer and not worry about import/export. At the DevCon I talked to developers who can get a feature request (a new report, function, whatever) from a client, add it onto their interface file, email it to the client and that

[Kundinger]

Hey, hey, hey... enuf with the geography jokes... everyone on the FMForums has jokes about one place or another. Having been born into the military outside the USA, then traveled and/or resided in 26 countries and 48 US states... I can say that I have heard a lot of them.

Living in Bismarck (not Bismark), North Dakota is not all that bad... it has it's advantages and some disadvantages. I've visited and lived in 'worse' places. One reason I'm here in ND is because we have a family farm/ranch on the North Dakota & Montana state line... now, you want to hear jokes... "Where Does Mountain Time Begin?"

There is one place in this world that seems to be the "Butt" of some of the worst or most 'wicked' geography jokes around... if you want to call them jokes. I'm not going to mention the place, especially because I was born there, but most people have heard of the place and have nothing nice to say of it. I doubt FMForums has any members from there... at least none that will admit it.

Bob

[keshalyi]

*Stares at bob askance , trying to decide if he's a Newfie, a PEI-er, a Texan, or a resident of 3-Mile Island*

Being an army brat myself, I have the snobbish advantage of being ble to make fun of any geographic locale without the shame of htinking I'm mocking my homeland. Unless you count Allied Headquarters in Shape Belgium back in the CW days, and frankly, while it deserves jokes, I don't think it ever got any. Not to mention my memory of the place goes something like *waah-waah-ooh-bottle-sleep-waah-waah*

At any rate...

I agree, there are situations like this where its nice to have the data seperated. Honestly, though, there's not a lot of ways to read up on it, as I think has been said. The best way is to just get started, here's what I've done buidling seperate structures, because the differece between data and structure is sometimes fuzzy.

Get two pieces of paper, and on one sheet write everything that is pure, atomic data. Then, on the other, write all the data derived from this data (Calculation fields, basically in FM). Then, build a db that has the first sheet, relate it to another db, and build a key to the first, and all those things on the second sheet. Now, BEFORE you start building pretty layouts and stuff, save both of these, in their raw, data-calc form. Then, its just a matter of playing with it. Honestly, I know that's irritating but you just have to play. Once you get over the fact that every floggin' thing you do you do basically with a relationship, its not that much different than building a normal db. Happy trails!

[Kundinger]

"Stares at bob askance , trying to decide if he's a Newfie, a PEI-er, a Texan, or a resident of 3-Mile Island"

I'm 'slow' in the 'Shakespean' lingo... unsure what "Stares at bob askance" means. What is "a Newfie, a PEI-er".

I know the rest... of which I'm not... although I lived/worked in various places in Texas while in the 'Oil' business. My mother lives there now in a place that grows 'nuts' on trees located 'between' two other places.

I was a US Air Force brat... travelling to many places... once lived about 60 miles east of SHAPE.

[brownees]

Keshalyi wrote

"Get two pieces of paper, and on one sheet write everything that is pure, atomic data. Then, on the other, write all the data derived from this data (Calculation fields, basically in FM). Then, build a db that has the first sheet, relate it to another db, and build a key to the first, and all those things on the second sheet. Now, BEFORE you start building pretty layouts and stuff, save both of these, in their raw, data-calc form. Then, its just a matter of playing with it. Honestly, I know that's irritating but you just have to play. Once you get over the fact that every floggin' thing you do you do basically with a relationship, its not that much different than building a normal db. Happy trails!"

Can you please elaborate. Do you build the presentation in the datacalc file?

[keshalyi]

First off, I apologise, Bob, I wax nerdy when I'm tired. Staring askance is roughly approximate to leering suspiciously out of the corner of your eye. Roughly. A PEI-er is a Prince Edward Island resident and a Newfie is a Newfoundlander, for those of us without Canadian relatives or roots.

At any rate, I know its been a while since I wrote, so hopefully my advice isn't totally defunct.

Here goes -

You have your two files, on holds Data, pure data, the stuff you actually type in and store in and of itself. This is ALL this db should hold.

The other holds calculations, in other words, numbers and values DERIVED from data - this seperates the structure (calculations, scripts, etc) from the actual data (typed in values). Then, build your user interface in the calc file.

This gives you all teh advantages (at least that I know of...) of data/structure segregation. I like to do it this way, because it keeps my data uncluttered and easy to access, while allowing me to centralize all my calculations and what not in a seperate database. Of course, like any rule of relational theory, you will break this one, numerous times, to be honest, I end up breaking it so many times taht I usually just don't bother with the segregation at all. For instance, if you need to relate the raw data to some other file, say, a file of invoice lines, you may well have to build some calcs in the raw data table, so you can index them and build a relationship off of them.

For that reason, others I know builid all the calcs and data and stuff all in the same big file, and then build a seperate file that basically just has layouts and interfaces in it, that hte user uses to interact with the other file. Frankly, I've seldom seen the advantage of this approach - why not just build the layouts in the same file, instead of pulling data into them over a relationship? - but there've been sitautions where it was a better choice, I've seen, and many people swear by it. It all depends on WHY you want to seperate data and structure. For instance, if you want to seperate them so that you can easily update your reporting and data handling calculations, scripts, layouts etc, then take my first approach - all you have to do is build a new Calc file, link them back up, and voila, you have what you want. If you are looking for security, from the setup... eh, ask someone smarter than me. My clients usually don't have too much of a security risk, and a lot of the segregated solutions I've seen were actually LESS secure - the more complex you make a structure, the more likely you'll miss a hole that a hacker won't.

Anyways, good luck, I'll try to check in more regularly from now on, I promise.

And watche out for those Newfies! They're crazy!

[Kundinger]

Hey 'keshalyi',

What's with the 'Newfie' comments? Have you been there? Is it that badddd?

Bob

[keshalyi]

*grin*

As the child of an Alberta native, its irrelevant what newfies are really like. Its like the Candian equivalent of Redneck jokes. Sure there are some very nice rednecks in the worlds, I'm sure, and lets face it, most of the purveyors of redneck jokes in this world have never MET a redneck, much less had a chance to truly judge them. Nonetheless its a convenient medium.

But I HAVE met Newfies before. They're weird. I think the sea addles their brains... ;P

[Kundinger]

Being 'Canook' or at least having 'Canook' family would explain your 'appreciation' of Newfies. I was curious as to how you knew so much about them. Most people in the states don't know who they are or where their from. Heck... many Canadians don't know about NFLD either.

I like your analogy of 'redneck'. It's ironic that you used the 'redneck' for your analogy... whenever I'm doing work in Minnesota, I hear similar 'comments' about Iowans!!!

Anyways... I've been to NFLD a 'few' times in my life... hope to take my daughter there someday. NFLD seems to be getting more popular with the 'southerners' since 9-11 and the Kevin Spacey's movie... "The Shipping News". There have also been a number of shows on the Travel Channel about NFLD.