<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: An Overview of the Six Fried Rice Methodology</title>
	<atom:link href="http://sixfriedrice.com/wp/an-overview-of-the-six-fried-rice-methodology/feed/" rel="self" type="application/rss+xml" />
	<link>http://sixfriedrice.com/wp/an-overview-of-the-six-fried-rice-methodology/</link>
	<description>smart business solutions</description>
	<lastBuildDate>Sun, 29 Jan 2012 19:10:42 -0600</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Tom</title>
		<link>http://sixfriedrice.com/wp/an-overview-of-the-six-fried-rice-methodology/comment-page-1/#comment-2077</link>
		<dc:creator>Tom</dc:creator>
		<pubDate>Sun, 18 Sep 2011 18:43:28 +0000</pubDate>
		<guid isPermaLink="false">http://sixfriedrice.com/wp/an-overview-of-the-six-fried-rice-methodology/#comment-2077</guid>
		<description>After posting my question, I realize you wouldn&#039;t need to do that sort of thing at all; it looks like you could just keep the same file names, but keep your development data and interface files (with the same names as production versions) in a different directory. Then, when you want to use the new interface, drop the new interface file into the production directory.</description>
		<content:encoded><![CDATA[<p>After posting my question, I realize you wouldn&#8217;t need to do that sort of thing at all; it looks like you could just keep the same file names, but keep your development data and interface files (with the same names as production versions) in a different directory. Then, when you want to use the new interface, drop the new interface file into the production directory.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tom</title>
		<link>http://sixfriedrice.com/wp/an-overview-of-the-six-fried-rice-methodology/comment-page-1/#comment-2076</link>
		<dc:creator>Tom</dc:creator>
		<pubDate>Sun, 18 Sep 2011 18:32:33 +0000</pubDate>
		<guid isPermaLink="false">http://sixfriedrice.com/wp/an-overview-of-the-six-fried-rice-methodology/#comment-2076</guid>
		<description>Hi 

I realize this post is from a while back, but I just ran across it. I like the idea of data separation, but have a question about hooking up the interface file to the data file (after you&#039;ve been working on the interface and want to point the new interface file to the production data file). Is there a way to automate changing the file references for each table occurrence, or do you have to do it manually for each TO in the relationship graph?

Or, do you leave your interface file hooked up to the production data file when you are doing development work on it?

Thanks,

Tom</description>
		<content:encoded><![CDATA[<p>Hi </p>
<p>I realize this post is from a while back, but I just ran across it. I like the idea of data separation, but have a question about hooking up the interface file to the data file (after you&#8217;ve been working on the interface and want to point the new interface file to the production data file). Is there a way to automate changing the file references for each table occurrence, or do you have to do it manually for each TO in the relationship graph?</p>
<p>Or, do you leave your interface file hooked up to the production data file when you are doing development work on it?</p>
<p>Thanks,</p>
<p>Tom</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Hans Erik</title>
		<link>http://sixfriedrice.com/wp/an-overview-of-the-six-fried-rice-methodology/comment-page-1/#comment-2058</link>
		<dc:creator>Hans Erik</dc:creator>
		<pubDate>Tue, 21 Jun 2011 20:47:10 +0000</pubDate>
		<guid isPermaLink="false">http://sixfriedrice.com/wp/an-overview-of-the-six-fried-rice-methodology/#comment-2058</guid>
		<description>Oops,
In my previous post I made a mistake: the external data source ofcourse is redirected from Y (testing) to X (production).

FileMaker 6 and before made a complete mess of data sources! So perhaps that&#039;s a reason most FMP developers I know take it for granted: they don&#039;t dare to look into it, afraid to mess things up...

HE</description>
		<content:encoded><![CDATA[<p>Oops,<br />
In my previous post I made a mistake: the external data source ofcourse is redirected from Y (testing) to X (production).</p>
<p>FileMaker 6 and before made a complete mess of data sources! So perhaps that&#8217;s a reason most FMP developers I know take it for granted: they don&#8217;t dare to look into it, afraid to mess things up&#8230;</p>
<p>HE</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Hans Erik</title>
		<link>http://sixfriedrice.com/wp/an-overview-of-the-six-fried-rice-methodology/comment-page-1/#comment-2057</link>
		<dc:creator>Hans Erik</dc:creator>
		<pubDate>Tue, 21 Jun 2011 20:01:52 +0000</pubDate>
		<guid isPermaLink="false">http://sixfriedrice.com/wp/an-overview-of-the-six-fried-rice-methodology/#comment-2057</guid>
		<description>Hi,

I did a Google Search on data separation and hit your comments. I fully support the data separation model, even for smaller solutions and there more reasons than ever for this, because you can easily make two interface files, one for desktop and one for FileMaker Go!
But that&#039;s not the point. I have a question: normally you have N interface files and 1 datafile (or more than 1, but each is unique in that it holds a certain set of data). But how about setting up a test environment? So you have one production database with UI files P1 and P2 pointing to datafile X. And you have a testing database residing on the same server with UI files T1 and T2 pointing to datafile Y. 

Users can test whatever they need to in T1 and T2: it&#039;s a test set.
When it&#039;s time to move to production, T1 is renamed to P1 (or P1a) and the external data source for X is redirected to Y.

X and Y are identical, except for their contents (test vs production).

Would this work reliably? I dug my way through the training series, but in my view, this is largely unexplored terrain. Yet with ORACLE or SQL Server, this is common practice!

Thanks,

Hans Erik</description>
		<content:encoded><![CDATA[<p>Hi,</p>
<p>I did a Google Search on data separation and hit your comments. I fully support the data separation model, even for smaller solutions and there more reasons than ever for this, because you can easily make two interface files, one for desktop and one for FileMaker Go!<br />
But that&#8217;s not the point. I have a question: normally you have N interface files and 1 datafile (or more than 1, but each is unique in that it holds a certain set of data). But how about setting up a test environment? So you have one production database with UI files P1 and P2 pointing to datafile X. And you have a testing database residing on the same server with UI files T1 and T2 pointing to datafile Y. </p>
<p>Users can test whatever they need to in T1 and T2: it&#8217;s a test set.<br />
When it&#8217;s time to move to production, T1 is renamed to P1 (or P1a) and the external data source for X is redirected to Y.</p>
<p>X and Y are identical, except for their contents (test vs production).</p>
<p>Would this work reliably? I dug my way through the training series, but in my view, this is largely unexplored terrain. Yet with ORACLE or SQL Server, this is common practice!</p>
<p>Thanks,</p>
<p>Hans Erik</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Daniel Niroumand</title>
		<link>http://sixfriedrice.com/wp/an-overview-of-the-six-fried-rice-methodology/comment-page-1/#comment-2045</link>
		<dc:creator>Daniel Niroumand</dc:creator>
		<pubDate>Fri, 18 Mar 2011 09:23:01 +0000</pubDate>
		<guid isPermaLink="false">http://sixfriedrice.com/wp/an-overview-of-the-six-fried-rice-methodology/#comment-2045</guid>
		<description>there is a question:  Using Filemaker Server, having a database File,and 2 Interface file all hosted on the Server. there is also a client file that will only open interface file .
the matter of authentication and user acces is a problem for me here.
where should i do all the authentications?  how should i pass the current logged on user to diffrent UI or Database File?
what is the solution?</description>
		<content:encoded><![CDATA[<p>there is a question:  Using Filemaker Server, having a database File,and 2 Interface file all hosted on the Server. there is also a client file that will only open interface file .<br />
the matter of authentication and user acces is a problem for me here.<br />
where should i do all the authentications?  how should i pass the current logged on user to diffrent UI or Database File?<br />
what is the solution?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jamie</title>
		<link>http://sixfriedrice.com/wp/an-overview-of-the-six-fried-rice-methodology/comment-page-1/#comment-1750</link>
		<dc:creator>Jamie</dc:creator>
		<pubDate>Tue, 07 Apr 2009 18:26:50 +0000</pubDate>
		<guid isPermaLink="false">http://sixfriedrice.com/wp/an-overview-of-the-six-fried-rice-methodology/#comment-1750</guid>
		<description>I migrated a very large file (over a gigabyte) from a single file configuration to a separated structure, similar to what you described here.  Both forms were hosted on the same FileMaker Server 8 Advanced.  I experienced a significant degradation in performance.  Certain scrips that had been manageable became so slow as to be unusable.  I wish I could remember the details of what was slower, but it&#039;s been over a year.

Have you done any comparisons of performance between single file systems and double file systems?  Did you encounter speed issues?  Have changes been made in FM9 and FM10 that might mitigate such issues?</description>
		<content:encoded><![CDATA[<p>I migrated a very large file (over a gigabyte) from a single file configuration to a separated structure, similar to what you described here.  Both forms were hosted on the same FileMaker Server 8 Advanced.  I experienced a significant degradation in performance.  Certain scrips that had been manageable became so slow as to be unusable.  I wish I could remember the details of what was slower, but it&#8217;s been over a year.</p>
<p>Have you done any comparisons of performance between single file systems and double file systems?  Did you encounter speed issues?  Have changes been made in FM9 and FM10 that might mitigate such issues?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jack James</title>
		<link>http://sixfriedrice.com/wp/an-overview-of-the-six-fried-rice-methodology/comment-page-1/#comment-1696</link>
		<dc:creator>Jack James</dc:creator>
		<pubDate>Thu, 26 Feb 2009 19:02:33 +0000</pubDate>
		<guid isPermaLink="false">http://sixfriedrice.com/wp/an-overview-of-the-six-fried-rice-methodology/#comment-1696</guid>
		<description>I employ the data separation model wherever possible. It makes life easier, keeps things easy to comprehend and document and keeps the overall complexity of a solution down. 

But I don&#039;t think that it really helps for maintaining a system.

Even if you take the best implementation of a system, where there are no calculation fields or relationships used outside of the UI file, it is inevitable that with almost every upgrade (particularly in a larger system) there will be a need to add a new field somewhere. This is true even in PHP/MySQL solutions almost every upgrade will require changes to the MySQL database in some way (it&#039;s just those changes can be scripted).

The problem with this system is that it&#039;s all or nothing: if I even have to change or add a single field outside of the UI file, then all the hard work I&#039;ve done trying to keep things as separate as possible are for nothing.

Note that I&#039;m not knocking the methodology at all; as I said, I use it myself as much as possible. But I&#039;ve yet to find a FM solution where upgrading is as easy as swapping out a file...</description>
		<content:encoded><![CDATA[<p>I employ the data separation model wherever possible. It makes life easier, keeps things easy to comprehend and document and keeps the overall complexity of a solution down. </p>
<p>But I don&#8217;t think that it really helps for maintaining a system.</p>
<p>Even if you take the best implementation of a system, where there are no calculation fields or relationships used outside of the UI file, it is inevitable that with almost every upgrade (particularly in a larger system) there will be a need to add a new field somewhere. This is true even in PHP/MySQL solutions almost every upgrade will require changes to the MySQL database in some way (it&#8217;s just those changes can be scripted).</p>
<p>The problem with this system is that it&#8217;s all or nothing: if I even have to change or add a single field outside of the UI file, then all the hard work I&#8217;ve done trying to keep things as separate as possible are for nothing.</p>
<p>Note that I&#8217;m not knocking the methodology at all; as I said, I use it myself as much as possible. But I&#8217;ve yet to find a FM solution where upgrading is as easy as swapping out a file&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Geoff Coffey</title>
		<link>http://sixfriedrice.com/wp/an-overview-of-the-six-fried-rice-methodology/comment-page-1/#comment-1695</link>
		<dc:creator>Geoff Coffey</dc:creator>
		<pubDate>Thu, 26 Feb 2009 17:55:35 +0000</pubDate>
		<guid isPermaLink="false">http://sixfriedrice.com/wp/an-overview-of-the-six-fried-rice-methodology/#comment-1695</guid>
		<description>Mike:

Relationships in the data file &lt;strong&gt;do not&lt;/strong&gt; show up in the UI file in any way. So if a relationship is used in both places, it needs to be defined in both places.

In general relationships in the data file are needed for calculation fields. All other relationships (used for portals, layouts, scripts, etc...) go in the UI file.

Hope that helps.

Geoff</description>
		<content:encoded><![CDATA[<p>Mike:</p>
<p>Relationships in the data file <strong>do not</strong> show up in the UI file in any way. So if a relationship is used in both places, it needs to be defined in both places.</p>
<p>In general relationships in the data file are needed for calculation fields. All other relationships (used for portals, layouts, scripts, etc&#8230;) go in the UI file.</p>
<p>Hope that helps.</p>
<p>Geoff</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mike Bush</title>
		<link>http://sixfriedrice.com/wp/an-overview-of-the-six-fried-rice-methodology/comment-page-1/#comment-1692</link>
		<dc:creator>Mike Bush</dc:creator>
		<pubDate>Thu, 26 Feb 2009 04:36:51 +0000</pubDate>
		<guid isPermaLink="false">http://sixfriedrice.com/wp/an-overview-of-the-six-fried-rice-methodology/#comment-1692</guid>
		<description>Geoff:

Is there a case where a relationship defined in the Data file must be redefined in the UI file too?  Does the UI file automatically &quot;know&quot; about relationships already defined in the data file without any extra work?</description>
		<content:encoded><![CDATA[<p>Geoff:</p>
<p>Is there a case where a relationship defined in the Data file must be redefined in the UI file too?  Does the UI file automatically &#8220;know&#8221; about relationships already defined in the data file without any extra work?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Daniel Antunes</title>
		<link>http://sixfriedrice.com/wp/an-overview-of-the-six-fried-rice-methodology/comment-page-1/#comment-1397</link>
		<dc:creator>Daniel Antunes</dc:creator>
		<pubDate>Tue, 16 Dec 2008 22:39:22 +0000</pubDate>
		<guid isPermaLink="false">http://sixfriedrice.com/wp/an-overview-of-the-six-fried-rice-methodology/#comment-1397</guid>
		<description>Otman:

There is definitely a threshold below which data separation, while a good practice, simply is not needed.  Personally, I like to use a data separated system for just about all of my projects, but it&#039;s more academic in some cases.  A few times it&#039;s actually come in amazingly helpful when the system I originally thought was going to be small ends up becoming a fully fleshed out application.  Planning for growth even if you don&#039;t see it can be a useful strategy!</description>
		<content:encoded><![CDATA[<p>Otman:</p>
<p>There is definitely a threshold below which data separation, while a good practice, simply is not needed.  Personally, I like to use a data separated system for just about all of my projects, but it&#8217;s more academic in some cases.  A few times it&#8217;s actually come in amazingly helpful when the system I originally thought was going to be small ends up becoming a fully fleshed out application.  Planning for growth even if you don&#8217;t see it can be a useful strategy!</p>
]]></content:encoded>
	</item>
</channel>
</rss>

