ESS Puzzle - Approximate Sorting?

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

ESS Puzzle - Approximate Sorting?

Stephen Wonfor-3
Hi

I have an 15” MBPro running 10.11.6 and FMPA15.0.3.305 and a 17” MBPro running 10.12.1 and FMPA15.0.3.305.
Both are logged into the same database (for certain - changes made in one show in the other right away).
Both on on the same layout.
There is a simple portal to an ESS Table.  The connection between local and ESS is via a global field - checkbox with values 0 and 1.  This is linked to a field in the ESS table called “fm_viewstate”.  This field allows the user to see external data that has been processed and/or external data that is new (from an online registration system).  The portal is unsorted and unfiltered.

Why am I rambling on about this?

MB15 sees 421 {{RecordNumber}} rows in the portal, with name “Gavan” in row one and “Geoffrey” in row 421.
MB17 sees 421 {{RecordNumber}} rows in the portal, with name “Carl” in row one and “Geoffrey” in row 421.
When I go to the FMP layout - both machines - I see that there are 421 records.  Both show as unsorted.
Yet I see “Carl” as first record on MB17 and I see “Gavan” as first record on MB15.  “Gavan” is record 244 on the MB17.

This does not really make sense.  I wish it did.  Different “unsort” states from machine to machine?  I note that when I sort the portal data occurs in the correct sequence.  When I remove the portal sorting (performance killer) each machine gets a different record in the portal at row 1.


Stephen

----------

"Never lend books -- nobody ever returns them; the only books I have in my library are those which people have lent me." --- Anatole France

_______________________________________________
FMPexperts mailing list
[hidden email]
http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
Reply | Threaded
Open this post in threaded view
|

Re: ESS Puzzle - Approximate Sorting?

Richard DeShong
Are you saying that on the MB15 you always get Gavan as 1st, and on the
MB17 you always get Carl?

If so, then I don't have an answer.

If you notice that the "unsorted" order of the records is different
(note no mention of "always"), then it relates to the source db.   In a
SQL db, when you issue a query, there is a "query optimizer" that runs
to try to pull records as efficiently as possible.  A primary
optimization is to use parallel requests. This means it breaks up your
query into multiple processes, running in multiple cpu spaces.  Then it
packages up the results and sends it off to your server.

So if the source is not specifying a sort order as part of the query,
then result set can be in different orders.



On 4/13/2017 12:12 PM, Stephen Wonfor wrote:

> Hi
>
> I have an 15” MBPro running 10.11.6 and FMPA15.0.3.305 and a 17” MBPro running 10.12.1 and FMPA15.0.3.305.
> Both are logged into the same database (for certain - changes made in one show in the other right away).
> Both on on the same layout.
> There is a simple portal to an ESS Table.  The connection between local and ESS is via a global field - checkbox with values 0 and 1.  This is linked to a field in the ESS table called “fm_viewstate”.  This field allows the user to see external data that has been processed and/or external data that is new (from an online registration system).  The portal is unsorted and unfiltered.
>
> Why am I rambling on about this?
>
> MB15 sees 421 {{RecordNumber}} rows in the portal, with name “Gavan” in row one and “Geoffrey” in row 421.
> MB17 sees 421 {{RecordNumber}} rows in the portal, with name “Carl” in row one and “Geoffrey” in row 421.
> When I go to the FMP layout - both machines - I see that there are 421 records.  Both show as unsorted.
> Yet I see “Carl” as first record on MB17 and I see “Gavan” as first record on MB15.  “Gavan” is record 244 on the MB17.
>
> This does not really make sense.  I wish it did.  Different “unsort” states from machine to machine?  I note that when I sort the portal data occurs in the correct sequence.  When I remove the portal sorting (performance killer) each machine gets a different record in the portal at row 1.
>
>
> Stephen
>
> ----------
>
> "Never lend books -- nobody ever returns them; the only books I have in my library are those which people have lent me." --- Anatole France
>
> _______________________________________________
> FMPexperts mailing list
> [hidden email]
> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au

--
Richard DeShong
Logic Tools
510-642-5123 office
925-285-1088 cell

_______________________________________________
FMPexperts mailing list
[hidden email]
http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
Reply | Threaded
Open this post in threaded view
|

Re: ESS Puzzle - Approximate Sorting?

Stephen Wonfor-3
Richard

Thanks.  And yes indeed to your first question - Always Gavan on the MB15 and Carl on the MB17.  The “sort” order for each is the same - no sort order - but the data appears in different orders.

Regarding your second thought - might the issue then be the actual MBPros hardware exerting some kind of influence on the communications between MBPro….>FMS15….>ESS……>FMS15….>MBPro?

Stephen

---

"The real problem is not whether machines think but whether men do." --- B. F. Skinner

> On Apr 13, 2017, at 2:13 PM, Richard DeShong <[hidden email]> wrote:
>
> Are you saying that on the MB15 you always get Gavan as 1st, and on the MB17 you always get Carl?
>
> If so, then I don't have an answer.
>
> If you notice that the "unsorted" order of the records is different (note no mention of "always"), then it relates to the source db.   In a SQL db, when you issue a query, there is a "query optimizer" that runs to try to pull records as efficiently as possible.  A primary optimization is to use parallel requests. This means it breaks up your query into multiple processes, running in multiple cpu spaces.  Then it packages up the results and sends it off to your server.
>
> So if the source is not specifying a sort order as part of the query, then result set can be in different orders.
>
>
>
> On 4/13/2017 12:12 PM, Stephen Wonfor wrote:
>> Hi
>>
>> I have an 15” MBPro running 10.11.6 and FMPA15.0.3.305 and a 17” MBPro running 10.12.1 and FMPA15.0.3.305.
>> Both are logged into the same database (for certain - changes made in one show in the other right away).
>> Both on on the same layout.
>> There is a simple portal to an ESS Table.  The connection between local and ESS is via a global field - checkbox with values 0 and 1.  This is linked to a field in the ESS table called “fm_viewstate”.  This field allows the user to see external data that has been processed and/or external data that is new (from an online registration system).  The portal is unsorted and unfiltered.
>>
>> Why am I rambling on about this?
>>
>> MB15 sees 421 {{RecordNumber}} rows in the portal, with name “Gavan” in row one and “Geoffrey” in row 421.
>> MB17 sees 421 {{RecordNumber}} rows in the portal, with name “Carl” in row one and “Geoffrey” in row 421.
>> When I go to the FMP layout - both machines - I see that there are 421 records.  Both show as unsorted.
>> Yet I see “Carl” as first record on MB17 and I see “Gavan” as first record on MB15.  “Gavan” is record 244 on the MB17.
>>
>> This does not really make sense.  I wish it did.  Different “unsort” states from machine to machine?  I note that when I sort the portal data occurs in the correct sequence.  When I remove the portal sorting (performance killer) each machine gets a different record in the portal at row 1.
>>
>>
>> Stephen
>>
>> ----------
>>
>> "Never lend books -- nobody ever returns them; the only books I have in my library are those which people have lent me." --- Anatole France
>>
>> _______________________________________________
>> FMPexperts mailing list
>> [hidden email]
>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>
> --
> Richard DeShong
> Logic Tools
> 510-642-5123 office
> 925-285-1088 cell
>
> _______________________________________________
> FMPexperts mailing list
> [hidden email]
> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au

_______________________________________________
FMPexperts mailing list
[hidden email]
http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
Reply | Threaded
Open this post in threaded view
|

Re: ESS Puzzle - Approximate Sorting?

Richard DeShong
My second point was to try to help you with your statement "This does
not really make sense".  It doesn't make sense if you believe that all
db servers behave the same way as FMS.  Here are a few points:

1) In an enterprise sql system, a single table can span multiple db
files.  And new records can be written to any of the files (meaning,
it's not just old records in file1 and new records in file2, 3, or ...).

2) Depending on how your connection is configured (at the server level,
not the dsn), a single query statement can be executed using a "set"
size (similar to how you might get back 10 rcds at a time in a web
interface).

3) Caching can change the retrieve order of records.

These, and more, can combine with a multi-threaded environment to return
records in a different order even though the query is the same.

So if you do not specify a sort order on the FMS relationship side, then
you will get records in whatever order the sql server gives them to
you.  That is, if that's how FMS works with the cached sql data.

Caveat:  It's quite possible that none of this relates to your "silly"
(no sense) situation.  Just wanted to point out that sql servers do all
sorts of "funny" (not like FMS) stuff.


As an aside:  Also note that FMS does *not* return un-sorted results.  
(What? But I did not select a sort order in my relationship).  If you
don't specify a sort order, then FMS returns the records in creation
order.  For speed, most db servers return the records in their
"physical" order, and then perform any conditional processing if requested.




On 4/13/2017 1:20 PM, Stephen Wonfor wrote:

> Richard
>
> Thanks.  And yes indeed to your first question - Always Gavan on the MB15 and Carl on the MB17.  The “sort” order for each is the same - no sort order - but the data appears in different orders.
>
> Regarding your second thought - might the issue then be the actual MBPros hardware exerting some kind of influence on the communications between MBPro….>FMS15….>ESS……>FMS15….>MBPro?
>
> Stephen
>
> ---
>
> "The real problem is not whether machines think but whether men do." --- B. F. Skinner
>
>> On Apr 13, 2017, at 2:13 PM, Richard DeShong <[hidden email]> wrote:
>>
>> Are you saying that on the MB15 you always get Gavan as 1st, and on the MB17 you always get Carl?
>>
>> If so, then I don't have an answer.
>>
>> If you notice that the "unsorted" order of the records is different (note no mention of "always"), then it relates to the source db.   In a SQL db, when you issue a query, there is a "query optimizer" that runs to try to pull records as efficiently as possible.  A primary optimization is to use parallel requests. This means it breaks up your query into multiple processes, running in multiple cpu spaces.  Then it packages up the results and sends it off to your server.
>>
>> So if the source is not specifying a sort order as part of the query, then result set can be in different orders.
>>
>>
>>
>> On 4/13/2017 12:12 PM, Stephen Wonfor wrote:
>>> Hi
>>>
>>> I have an 15” MBPro running 10.11.6 and FMPA15.0.3.305 and a 17” MBPro running 10.12.1 and FMPA15.0.3.305.
>>> Both are logged into the same database (for certain - changes made in one show in the other right away).
>>> Both on on the same layout.
>>> There is a simple portal to an ESS Table.  The connection between local and ESS is via a global field - checkbox with values 0 and 1.  This is linked to a field in the ESS table called “fm_viewstate”.  This field allows the user to see external data that has been processed and/or external data that is new (from an online registration system).  The portal is unsorted and unfiltered.
>>>
>>> Why am I rambling on about this?
>>>
>>> MB15 sees 421 {{RecordNumber}} rows in the portal, with name “Gavan” in row one and “Geoffrey” in row 421.
>>> MB17 sees 421 {{RecordNumber}} rows in the portal, with name “Carl” in row one and “Geoffrey” in row 421.
>>> When I go to the FMP layout - both machines - I see that there are 421 records.  Both show as unsorted.
>>> Yet I see “Carl” as first record on MB17 and I see “Gavan” as first record on MB15.  “Gavan” is record 244 on the MB17.
>>>
>>> This does not really make sense.  I wish it did.  Different “unsort” states from machine to machine?  I note that when I sort the portal data occurs in the correct sequence.  When I remove the portal sorting (performance killer) each machine gets a different record in the portal at row 1.
>>>
>>>
>>> Stephen
>>>
>>> ----------
>>>
>>> "Never lend books -- nobody ever returns them; the only books I have in my library are those which people have lent me." --- Anatole France
>>>
>>> _______________________________________________
>>> FMPexperts mailing list
>>> [hidden email]
>>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>> --
>> Richard DeShong
>> Logic Tools
>> 510-642-5123 office
>> 925-285-1088 cell
>>
>> _______________________________________________
>> FMPexperts mailing list
>> [hidden email]
>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
> _______________________________________________
> FMPexperts mailing list
> [hidden email]
> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au

--
Richard DeShong
Logic Tools
510-642-5123 office
925-285-1088 cell

_______________________________________________
FMPexperts mailing list
[hidden email]
http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
Reply | Threaded
Open this post in threaded view
|

Re: ESS Puzzle - Approximate Sorting?

Beverly Voth-3
please define 'db', 'table', 'file', 'enterprise sql'. :)

> On Apr 13, 2017, at 5:07 PM, Richard DeShong <[hidden email]> wrote:
>
> 1) In an enterprise sql system, a single table can span multiple db files.  And new records can be written to any of the files (meaning, it's not just old records in file1 and new records in file2, 3, or ...).

_______________________________________________
FMPexperts mailing list
[hidden email]
http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
Reply | Threaded
Open this post in threaded view
|

Re: ESS Puzzle - Approximate Sorting?

Stephen Wonfor-3
In reply to this post by Richard DeShong
Richard

Thanks so much for the ESS observations - I operate in FMP and have incidental exposure to ESS systems.  Basically I access the ESS tables and extract data from them and sometimes push the other way.  Interesting to know about the potential vagaries of the record display sequences.

Stephen

---

Age-otori (Japanese) To look worse after a haircut.

> On Apr 13, 2017, at 3:07 PM, Richard DeShong <[hidden email]> wrote:
>
> My second point was to try to help you with your statement "This does not really make sense".  It doesn't make sense if you believe that all db servers behave the same way as FMS.  Here are a few points:
>
> 1) In an enterprise sql system, a single table can span multiple db files.  And new records can be written to any of the files (meaning, it's not just old records in file1 and new records in file2, 3, or ...).
>
> 2) Depending on how your connection is configured (at the server level, not the dsn), a single query statement can be executed using a "set" size (similar to how you might get back 10 rcds at a time in a web interface).
>
> 3) Caching can change the retrieve order of records.
>
> These, and more, can combine with a multi-threaded environment to return records in a different order even though the query is the same.
>
> So if you do not specify a sort order on the FMS relationship side, then you will get records in whatever order the sql server gives them to you.  That is, if that's how FMS works with the cached sql data.
>
> Caveat:  It's quite possible that none of this relates to your "silly" (no sense) situation.  Just wanted to point out that sql servers do all sorts of "funny" (not like FMS) stuff.
>
>
> As an aside:  Also note that FMS does *not* return un-sorted results.  (What? But I did not select a sort order in my relationship).  If you don't specify a sort order, then FMS returns the records in creation order.  For speed, most db servers return the records in their "physical" order, and then perform any conditional processing if requested.
>
>
>
>
> On 4/13/2017 1:20 PM, Stephen Wonfor wrote:
>> Richard
>>
>> Thanks.  And yes indeed to your first question - Always Gavan on the MB15 and Carl on the MB17.  The “sort” order for each is the same - no sort order - but the data appears in different orders.
>>
>> Regarding your second thought - might the issue then be the actual MBPros hardware exerting some kind of influence on the communications between MBPro….>FMS15….>ESS……>FMS15….>MBPro?
>>
>> Stephen
>>
>> ---
>>
>> "The real problem is not whether machines think but whether men do." --- B. F. Skinner
>>
>>> On Apr 13, 2017, at 2:13 PM, Richard DeShong <[hidden email]> wrote:
>>>
>>> Are you saying that on the MB15 you always get Gavan as 1st, and on the MB17 you always get Carl?
>>>
>>> If so, then I don't have an answer.
>>>
>>> If you notice that the "unsorted" order of the records is different (note no mention of "always"), then it relates to the source db.   In a SQL db, when you issue a query, there is a "query optimizer" that runs to try to pull records as efficiently as possible.  A primary optimization is to use parallel requests. This means it breaks up your query into multiple processes, running in multiple cpu spaces.  Then it packages up the results and sends it off to your server.
>>>
>>> So if the source is not specifying a sort order as part of the query, then result set can be in different orders.
>>>
>>>
>>>
>>> On 4/13/2017 12:12 PM, Stephen Wonfor wrote:
>>>> Hi
>>>>
>>>> I have an 15” MBPro running 10.11.6 and FMPA15.0.3.305 and a 17” MBPro running 10.12.1 and FMPA15.0.3.305.
>>>> Both are logged into the same database (for certain - changes made in one show in the other right away).
>>>> Both on on the same layout.
>>>> There is a simple portal to an ESS Table.  The connection between local and ESS is via a global field - checkbox with values 0 and 1.  This is linked to a field in the ESS table called “fm_viewstate”.  This field allows the user to see external data that has been processed and/or external data that is new (from an online registration system).  The portal is unsorted and unfiltered.
>>>>
>>>> Why am I rambling on about this?
>>>>
>>>> MB15 sees 421 {{RecordNumber}} rows in the portal, with name “Gavan” in row one and “Geoffrey” in row 421.
>>>> MB17 sees 421 {{RecordNumber}} rows in the portal, with name “Carl” in row one and “Geoffrey” in row 421.
>>>> When I go to the FMP layout - both machines - I see that there are 421 records.  Both show as unsorted.
>>>> Yet I see “Carl” as first record on MB17 and I see “Gavan” as first record on MB15.  “Gavan” is record 244 on the MB17.
>>>>
>>>> This does not really make sense.  I wish it did.  Different “unsort” states from machine to machine?  I note that when I sort the portal data occurs in the correct sequence.  When I remove the portal sorting (performance killer) each machine gets a different record in the portal at row 1.
>>>>
>>>>
>>>> Stephen
>>>>
>>>> ----------
>>>>
>>>> "Never lend books -- nobody ever returns them; the only books I have in my library are those which people have lent me." --- Anatole France
>>>>
>>>> _______________________________________________
>>>> FMPexperts mailing list
>>>> [hidden email]
>>>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>>> --
>>> Richard DeShong
>>> Logic Tools
>>> 510-642-5123 office
>>> 925-285-1088 cell
>>>
>>> _______________________________________________
>>> FMPexperts mailing list
>>> [hidden email]
>>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>> _______________________________________________
>> FMPexperts mailing list
>> [hidden email]
>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>
> --
> Richard DeShong
> Logic Tools
> 510-642-5123 office
> 925-285-1088 cell
>
> _______________________________________________
> FMPexperts mailing list
> [hidden email]
> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au

_______________________________________________
FMPexperts mailing list
[hidden email]
http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
Reply | Threaded
Open this post in threaded view
|

Re: ESS Puzzle - Approximate Sorting?

Stephen Wonfor-3
In reply to this post by Richard DeShong
Richard

Another question on this topic.

Again it involves the 2 MBPros.  Both are on the same db same layout all records showing.  
MB17 shows 406 records, MB15 shows 405.
I added a layout button to CommitRecords(no questions asked).  Still 406 vs 405.
I popped both from Browse to Layout to Browse.  Still 406 to 405.
I execute a FIND on both MBP’s.    Still 406 to 405.
What seems to work is quitting FMP and reconnecting.  Which, while effective, seems kludgy at best.
I gather there is a lag in the process - FMP to ESS.
<Subsequent Discovery> Refresh Window(no questions asked) works!

So is it your experience that “RefreshWindow” the ticket here?

It concerns me a bit that if I were reporting on things like TotalRecordCount I’d get different results for different user machines - which I just tested and I do get 406 vs 405.

Stephen

---

"if you can't talk to your cat about catnip, who will?"

> On Apr 13, 2017, at 3:07 PM, Richard DeShong <[hidden email]> wrote:
>
> My second point was to try to help you with your statement "This does not really make sense".  It doesn't make sense if you believe that all db servers behave the same way as FMS.  Here are a few points:
>
> 1) In an enterprise sql system, a single table can span multiple db files.  And new records can be written to any of the files (meaning, it's not just old records in file1 and new records in file2, 3, or ...).
>
> 2) Depending on how your connection is configured (at the server level, not the dsn), a single query statement can be executed using a "set" size (similar to how you might get back 10 rcds at a time in a web interface).
>
> 3) Caching can change the retrieve order of records.
>
> These, and more, can combine with a multi-threaded environment to return records in a different order even though the query is the same.
>
> So if you do not specify a sort order on the FMS relationship side, then you will get records in whatever order the sql server gives them to you.  That is, if that's how FMS works with the cached sql data.
>
> Caveat:  It's quite possible that none of this relates to your "silly" (no sense) situation.  Just wanted to point out that sql servers do all sorts of "funny" (not like FMS) stuff.
>
>
> As an aside:  Also note that FMS does *not* return un-sorted results.  (What? But I did not select a sort order in my relationship).  If you don't specify a sort order, then FMS returns the records in creation order.  For speed, most db servers return the records in their "physical" order, and then perform any conditional processing if requested.
>
>
>
>
> On 4/13/2017 1:20 PM, Stephen Wonfor wrote:
>> Richard
>>
>> Thanks.  And yes indeed to your first question - Always Gavan on the MB15 and Carl on the MB17.  The “sort” order for each is the same - no sort order - but the data appears in different orders.
>>
>> Regarding your second thought - might the issue then be the actual MBPros hardware exerting some kind of influence on the communications between MBPro….>FMS15….>ESS……>FMS15….>MBPro?
>>
>> Stephen
>>
>> ---
>>
>> "The real problem is not whether machines think but whether men do." --- B. F. Skinner
>>
>>> On Apr 13, 2017, at 2:13 PM, Richard DeShong <[hidden email]> wrote:
>>>
>>> Are you saying that on the MB15 you always get Gavan as 1st, and on the MB17 you always get Carl?
>>>
>>> If so, then I don't have an answer.
>>>
>>> If you notice that the "unsorted" order of the records is different (note no mention of "always"), then it relates to the source db.   In a SQL db, when you issue a query, there is a "query optimizer" that runs to try to pull records as efficiently as possible.  A primary optimization is to use parallel requests. This means it breaks up your query into multiple processes, running in multiple cpu spaces.  Then it packages up the results and sends it off to your server.
>>>
>>> So if the source is not specifying a sort order as part of the query, then result set can be in different orders.
>>>
>>>
>>>
>>> On 4/13/2017 12:12 PM, Stephen Wonfor wrote:
>>>> Hi
>>>>
>>>> I have an 15” MBPro running 10.11.6 and FMPA15.0.3.305 and a 17” MBPro running 10.12.1 and FMPA15.0.3.305.
>>>> Both are logged into the same database (for certain - changes made in one show in the other right away).
>>>> Both on on the same layout.
>>>> There is a simple portal to an ESS Table.  The connection between local and ESS is via a global field - checkbox with values 0 and 1.  This is linked to a field in the ESS table called “fm_viewstate”.  This field allows the user to see external data that has been processed and/or external data that is new (from an online registration system).  The portal is unsorted and unfiltered.
>>>>
>>>> Why am I rambling on about this?
>>>>
>>>> MB15 sees 421 {{RecordNumber}} rows in the portal, with name “Gavan” in row one and “Geoffrey” in row 421.
>>>> MB17 sees 421 {{RecordNumber}} rows in the portal, with name “Carl” in row one and “Geoffrey” in row 421.
>>>> When I go to the FMP layout - both machines - I see that there are 421 records.  Both show as unsorted.
>>>> Yet I see “Carl” as first record on MB17 and I see “Gavan” as first record on MB15.  “Gavan” is record 244 on the MB17.
>>>>
>>>> This does not really make sense.  I wish it did.  Different “unsort” states from machine to machine?  I note that when I sort the portal data occurs in the correct sequence.  When I remove the portal sorting (performance killer) each machine gets a different record in the portal at row 1.
>>>>
>>>>
>>>> Stephen
>>>>
>>>> ----------
>>>>
>>>> "Never lend books -- nobody ever returns them; the only books I have in my library are those which people have lent me." --- Anatole France
>>>>
>>>> _______________________________________________
>>>> FMPexperts mailing list
>>>> [hidden email]
>>>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>>> --
>>> Richard DeShong
>>> Logic Tools
>>> 510-642-5123 office
>>> 925-285-1088 cell
>>>
>>> _______________________________________________
>>> FMPexperts mailing list
>>> [hidden email]
>>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>> _______________________________________________
>> FMPexperts mailing list
>> [hidden email]
>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>
> --
> Richard DeShong
> Logic Tools
> 510-642-5123 office
> 925-285-1088 cell
>
> _______________________________________________
> FMPexperts mailing list
> [hidden email]
> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au

_______________________________________________
FMPexperts mailing list
[hidden email]
http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
Reply | Threaded
Open this post in threaded view
|

Re: ESS Puzzle - Approximate Sorting?

Jimmy D. Jones
My mantra is always and every time use Window Refresh Flush ESS Cache when Finding/updating/creating in any ESS table. FMP caches data and unless it requests the new data it doesn't automatically get updated. Because the ESS tables are separate from FMP, access is through the DSN Driver, there is no direct connection between FMP and the ESS tables and no auto update of the FMP cache of data. Clients can create, edit and even delete records and other clients will NOT know about them. The only way FMP knows to retrieve current data is when told to refresh the window, and then it's only the found set of records. When doing a Find only the set of records returned is updated in the FMP cache.

BTW, doing a refresh window with an ESS table of a million rows will be slow, how slow is unknowable. I suggest doing a Find for the required records before doing a Refresh.

___________
The opinions expressed in this email are my own and do not reflect those of my employer or anyone else.
Regards,
Ch0c0halic, FileMaker 14 Certified Developer
FileMaker Developer Conference 2017
July 24-26, 2017 • JW Marriott Desert Ridge, Phoenix, AZ
http://www.filemaker.com/learning/devcon/index.html

> On Apr 13, 2017, at 2:54 PM, Stephen Wonfor <[hidden email]> wrote:
>
> Richard
>
> Another question on this topic.
>
> Again it involves the 2 MBPros.  Both are on the same db same layout all records showing.  
> MB17 shows 406 records, MB15 shows 405.
> I added a layout button to CommitRecords(no questions asked).  Still 406 vs 405.
> I popped both from Browse to Layout to Browse.  Still 406 to 405.
> I execute a FIND on both MBP’s.    Still 406 to 405.
> What seems to work is quitting FMP and reconnecting.  Which, while effective, seems kludgy at best.
> I gather there is a lag in the process - FMP to ESS.
> <Subsequent Discovery> Refresh Window(no questions asked) works!
>
> So is it your experience that “RefreshWindow” the ticket here?
>
> It concerns me a bit that if I were reporting on things like TotalRecordCount I’d get different results for different user machines - which I just tested and I do get 406 vs 405.
>
> Stephen
>
> ---
>
> "if you can't talk to your cat about catnip, who will?"
>
>> On Apr 13, 2017, at 3:07 PM, Richard DeShong <[hidden email]> wrote:
>>
>> My second point was to try to help you with your statement "This does not really make sense".  It doesn't make sense if you believe that all db servers behave the same way as FMS.  Here are a few points:
>>
>> 1) In an enterprise sql system, a single table can span multiple db files.  And new records can be written to any of the files (meaning, it's not just old records in file1 and new records in file2, 3, or ...).
>>
>> 2) Depending on how your connection is configured (at the server level, not the dsn), a single query statement can be executed using a "set" size (similar to how you might get back 10 rcds at a time in a web interface).
>>
>> 3) Caching can change the retrieve order of records.
>>
>> These, and more, can combine with a multi-threaded environment to return records in a different order even though the query is the same.
>>
>> So if you do not specify a sort order on the FMS relationship side, then you will get records in whatever order the sql server gives them to you.  That is, if that's how FMS works with the cached sql data.
>>
>> Caveat:  It's quite possible that none of this relates to your "silly" (no sense) situation.  Just wanted to point out that sql servers do all sorts of "funny" (not like FMS) stuff.
>>
>>
>> As an aside:  Also note that FMS does *not* return un-sorted results.  (What? But I did not select a sort order in my relationship).  If you don't specify a sort order, then FMS returns the records in creation order.  For speed, most db servers return the records in their "physical" order, and then perform any conditional processing if requested.
>>
>>
>>
>>
>> On 4/13/2017 1:20 PM, Stephen Wonfor wrote:
>>> Richard
>>>
>>> Thanks.  And yes indeed to your first question - Always Gavan on the MB15 and Carl on the MB17.  The “sort” order for each is the same - no sort order - but the data appears in different orders.
>>>
>>> Regarding your second thought - might the issue then be the actual MBPros hardware exerting some kind of influence on the communications between MBPro….>FMS15….>ESS……>FMS15….>MBPro?
>>>
>>> Stephen
>>>
>>> ---
>>>
>>> "The real problem is not whether machines think but whether men do." --- B. F. Skinner
>>>
>>>> On Apr 13, 2017, at 2:13 PM, Richard DeShong <[hidden email]> wrote:
>>>>
>>>> Are you saying that on the MB15 you always get Gavan as 1st, and on the MB17 you always get Carl?
>>>>
>>>> If so, then I don't have an answer.
>>>>
>>>> If you notice that the "unsorted" order of the records is different (note no mention of "always"), then it relates to the source db.   In a SQL db, when you issue a query, there is a "query optimizer" that runs to try to pull records as efficiently as possible.  A primary optimization is to use parallel requests. This means it breaks up your query into multiple processes, running in multiple cpu spaces.  Then it packages up the results and sends it off to your server.
>>>>
>>>> So if the source is not specifying a sort order as part of the query, then result set can be in different orders.
>>>>
>>>>
>>>>
>>>> On 4/13/2017 12:12 PM, Stephen Wonfor wrote:
>>>>> Hi
>>>>>
>>>>> I have an 15” MBPro running 10.11.6 and FMPA15.0.3.305 and a 17” MBPro running 10.12.1 and FMPA15.0.3.305.
>>>>> Both are logged into the same database (for certain - changes made in one show in the other right away).
>>>>> Both on on the same layout.
>>>>> There is a simple portal to an ESS Table.  The connection between local and ESS is via a global field - checkbox with values 0 and 1.  This is linked to a field in the ESS table called “fm_viewstate”.  This field allows the user to see external data that has been processed and/or external data that is new (from an online registration system).  The portal is unsorted and unfiltered.
>>>>>
>>>>> Why am I rambling on about this?
>>>>>
>>>>> MB15 sees 421 {{RecordNumber}} rows in the portal, with name “Gavan” in row one and “Geoffrey” in row 421.
>>>>> MB17 sees 421 {{RecordNumber}} rows in the portal, with name “Carl” in row one and “Geoffrey” in row 421.
>>>>> When I go to the FMP layout - both machines - I see that there are 421 records.  Both show as unsorted.
>>>>> Yet I see “Carl” as first record on MB17 and I see “Gavan” as first record on MB15.  “Gavan” is record 244 on the MB17.
>>>>>
>>>>> This does not really make sense.  I wish it did.  Different “unsort” states from machine to machine?  I note that when I sort the portal data occurs in the correct sequence.  When I remove the portal sorting (performance killer) each machine gets a different record in the portal at row 1.
>>>>>
>>>>>
>>>>> Stephen
>>>>>
>>>>> ----------
>>>>>
>>>>> "Never lend books -- nobody ever returns them; the only books I have in my library are those which people have lent me." --- Anatole France
>>>>>
>>>>> _______________________________________________
>>>>> FMPexperts mailing list
>>>>> [hidden email]
>>>>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>>>> --
>>>> Richard DeShong
>>>> Logic Tools
>>>> 510-642-5123 office
>>>> 925-285-1088 cell
>>>>
>>>> _______________________________________________
>>>> FMPexperts mailing list
>>>> [hidden email]
>>>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>>> _______________________________________________
>>> FMPexperts mailing list
>>> [hidden email]
>>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>>
>> --
>> Richard DeShong
>> Logic Tools
>> 510-642-5123 office
>> 925-285-1088 cell
>>
>> _______________________________________________
>> FMPexperts mailing list
>> [hidden email]
>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>
> _______________________________________________
> FMPexperts mailing list
> [hidden email]
> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au

_______________________________________________
FMPexperts mailing list
[hidden email]
http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
Reply | Threaded
Open this post in threaded view
|

Re: ESS Puzzle - Approximate Sorting?

Stephen Wonfor-3
Jimmy

Nice advice.  To your last point - are you meaning that in an ESS table of many records you would do a FIND then refresh on that?  And only that data gets refreshed?  Would additional data that met the FIND criteria appear into the found set?

Stephen

---

Verschlimmbesserung:  A German word for an attempted improvement that just made things worse.

> On Apr 13, 2017, at 5:58 PM, Jimmy D. Jones <[hidden email]> wrote:
>
> My mantra is always and every time use Window Refresh Flush ESS Cache when Finding/updating/creating in any ESS table. FMP caches data and unless it requests the new data it doesn't automatically get updated. Because the ESS tables are separate from FMP, access is through the DSN Driver, there is no direct connection between FMP and the ESS tables and no auto update of the FMP cache of data. Clients can create, edit and even delete records and other clients will NOT know about them. The only way FMP knows to retrieve current data is when told to refresh the window, and then it's only the found set of records. When doing a Find only the set of records returned is updated in the FMP cache.
>
> BTW, doing a refresh window with an ESS table of a million rows will be slow, how slow is unknowable. I suggest doing a Find for the required records before doing a Refresh.
>
> ___________
> The opinions expressed in this email are my own and do not reflect those of my employer or anyone else.
> Regards,
> Ch0c0halic, FileMaker 14 Certified Developer
> FileMaker Developer Conference 2017
> July 24-26, 2017 • JW Marriott Desert Ridge, Phoenix, AZ
> http://www.filemaker.com/learning/devcon/index.html
>
>> On Apr 13, 2017, at 2:54 PM, Stephen Wonfor <[hidden email]> wrote:
>>
>> Richard
>>
>> Another question on this topic.
>>
>> Again it involves the 2 MBPros.  Both are on the same db same layout all records showing.  
>> MB17 shows 406 records, MB15 shows 405.
>> I added a layout button to CommitRecords(no questions asked).  Still 406 vs 405.
>> I popped both from Browse to Layout to Browse.  Still 406 to 405.
>> I execute a FIND on both MBP’s.    Still 406 to 405.
>> What seems to work is quitting FMP and reconnecting.  Which, while effective, seems kludgy at best.
>> I gather there is a lag in the process - FMP to ESS.
>> <Subsequent Discovery> Refresh Window(no questions asked) works!
>>
>> So is it your experience that “RefreshWindow” the ticket here?
>>
>> It concerns me a bit that if I were reporting on things like TotalRecordCount I’d get different results for different user machines - which I just tested and I do get 406 vs 405.
>>
>> Stephen
>>
>> ---
>>
>> "if you can't talk to your cat about catnip, who will?"
>>
>>> On Apr 13, 2017, at 3:07 PM, Richard DeShong <[hidden email]> wrote:
>>>
>>> My second point was to try to help you with your statement "This does not really make sense".  It doesn't make sense if you believe that all db servers behave the same way as FMS.  Here are a few points:
>>>
>>> 1) In an enterprise sql system, a single table can span multiple db files.  And new records can be written to any of the files (meaning, it's not just old records in file1 and new records in file2, 3, or ...).
>>>
>>> 2) Depending on how your connection is configured (at the server level, not the dsn), a single query statement can be executed using a "set" size (similar to how you might get back 10 rcds at a time in a web interface).
>>>
>>> 3) Caching can change the retrieve order of records.
>>>
>>> These, and more, can combine with a multi-threaded environment to return records in a different order even though the query is the same.
>>>
>>> So if you do not specify a sort order on the FMS relationship side, then you will get records in whatever order the sql server gives them to you.  That is, if that's how FMS works with the cached sql data.
>>>
>>> Caveat:  It's quite possible that none of this relates to your "silly" (no sense) situation.  Just wanted to point out that sql servers do all sorts of "funny" (not like FMS) stuff.
>>>
>>>
>>> As an aside:  Also note that FMS does *not* return un-sorted results.  (What? But I did not select a sort order in my relationship).  If you don't specify a sort order, then FMS returns the records in creation order.  For speed, most db servers return the records in their "physical" order, and then perform any conditional processing if requested.
>>>
>>>
>>>
>>>
>>> On 4/13/2017 1:20 PM, Stephen Wonfor wrote:
>>>> Richard
>>>>
>>>> Thanks.  And yes indeed to your first question - Always Gavan on the MB15 and Carl on the MB17.  The “sort” order for each is the same - no sort order - but the data appears in different orders.
>>>>
>>>> Regarding your second thought - might the issue then be the actual MBPros hardware exerting some kind of influence on the communications between MBPro….>FMS15….>ESS……>FMS15….>MBPro?
>>>>
>>>> Stephen
>>>>
>>>> ---
>>>>
>>>> "The real problem is not whether machines think but whether men do." --- B. F. Skinner
>>>>
>>>>> On Apr 13, 2017, at 2:13 PM, Richard DeShong <[hidden email]> wrote:
>>>>>
>>>>> Are you saying that on the MB15 you always get Gavan as 1st, and on the MB17 you always get Carl?
>>>>>
>>>>> If so, then I don't have an answer.
>>>>>
>>>>> If you notice that the "unsorted" order of the records is different (note no mention of "always"), then it relates to the source db.   In a SQL db, when you issue a query, there is a "query optimizer" that runs to try to pull records as efficiently as possible.  A primary optimization is to use parallel requests. This means it breaks up your query into multiple processes, running in multiple cpu spaces.  Then it packages up the results and sends it off to your server.
>>>>>
>>>>> So if the source is not specifying a sort order as part of the query, then result set can be in different orders.
>>>>>
>>>>>
>>>>>
>>>>> On 4/13/2017 12:12 PM, Stephen Wonfor wrote:
>>>>>> Hi
>>>>>>
>>>>>> I have an 15” MBPro running 10.11.6 and FMPA15.0.3.305 and a 17” MBPro running 10.12.1 and FMPA15.0.3.305.
>>>>>> Both are logged into the same database (for certain - changes made in one show in the other right away).
>>>>>> Both on on the same layout.
>>>>>> There is a simple portal to an ESS Table.  The connection between local and ESS is via a global field - checkbox with values 0 and 1.  This is linked to a field in the ESS table called “fm_viewstate”.  This field allows the user to see external data that has been processed and/or external data that is new (from an online registration system).  The portal is unsorted and unfiltered.
>>>>>>
>>>>>> Why am I rambling on about this?
>>>>>>
>>>>>> MB15 sees 421 {{RecordNumber}} rows in the portal, with name “Gavan” in row one and “Geoffrey” in row 421.
>>>>>> MB17 sees 421 {{RecordNumber}} rows in the portal, with name “Carl” in row one and “Geoffrey” in row 421.
>>>>>> When I go to the FMP layout - both machines - I see that there are 421 records.  Both show as unsorted.
>>>>>> Yet I see “Carl” as first record on MB17 and I see “Gavan” as first record on MB15.  “Gavan” is record 244 on the MB17.
>>>>>>
>>>>>> This does not really make sense.  I wish it did.  Different “unsort” states from machine to machine?  I note that when I sort the portal data occurs in the correct sequence.  When I remove the portal sorting (performance killer) each machine gets a different record in the portal at row 1.
>>>>>>
>>>>>>
>>>>>> Stephen
>>>>>>
>>>>>> ----------
>>>>>>
>>>>>> "Never lend books -- nobody ever returns them; the only books I have in my library are those which people have lent me." --- Anatole France
>>>>>>
>>>>>> _______________________________________________
>>>>>> FMPexperts mailing list
>>>>>> [hidden email]
>>>>>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>>>>> --
>>>>> Richard DeShong
>>>>> Logic Tools
>>>>> 510-642-5123 office
>>>>> 925-285-1088 cell
>>>>>
>>>>> _______________________________________________
>>>>> FMPexperts mailing list
>>>>> [hidden email]
>>>>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>>>> _______________________________________________
>>>> FMPexperts mailing list
>>>> [hidden email]
>>>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>>>
>>> --
>>> Richard DeShong
>>> Logic Tools
>>> 510-642-5123 office
>>> 925-285-1088 cell
>>>
>>> _______________________________________________
>>> FMPexperts mailing list
>>> [hidden email]
>>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>>
>> _______________________________________________
>> FMPexperts mailing list
>> [hidden email]
>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>
> _______________________________________________
> FMPexperts mailing list
> [hidden email]
> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au

_______________________________________________
FMPexperts mailing list
[hidden email]
http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
Reply | Threaded
Open this post in threaded view
|

Re: ESS Puzzle - Approximate Sorting?

Richard DeShong
In reply to this post by Beverly Voth-3
Sorry, a bit casual on word and abbreviation choices...

"db" was shorthand for "database", in the sense of a collection of
related tables.
"table" was the logical construct - same as used by FM - rows/records of
columns/fields.
"file" is referring to the operating system file system.
"enterprise sql" is, say, Microsoft SQL Server 2008 and above.

A typical database would have a "primary" file and a "log" file. So even
with this typical/standard setup, both are used to verify/update data in
a table.  But you can also have "secondary" files.  And a single table
can be partitioned and thus stored in multiple files.


On 4/13/2017 2:12 PM, BEVERLY VOTH wrote:
> please define 'db', 'table', 'file', 'enterprise sql'. :)
>
>> On Apr 13, 2017, at 5:07 PM, Richard DeShong <[hidden email]> wrote:
>>
>> 1) In an enterprise sql system, a single table can span multiple db files.  And new records can be written to any of the files (meaning, it's not just old records in file1 and new records in file2, 3, or ...).
> _______________________________________________
> FMPexperts mailing list
> [hidden email]
> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au

--
Richard DeShong
Logic Tools
510-642-5123 office
925-285-1088 cell

_______________________________________________
FMPexperts mailing list
[hidden email]
http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
Reply | Threaded
Open this post in threaded view
|

Re: ESS Puzzle - Approximate Sorting?

Jimmy D. Jones
In reply to this post by Stephen Wonfor-3
Stephen,

I do the Refresh after the Find. No additional data is returned after the refresh. However, the refresh does a flush cache of the ESS joins giving me fresh links to related tables. I've had issues with stale joins and found this makes it more reliable. If there is a chance other systems or clients could be editing data in records in my found set while I am traversing the records then I put a refresh after every record switch.

Pseudo code:
Go to Record/Request [Next]
Refresh with Flush Cache.

___________
Jimmy Jones
FileMaker 14 Certified Developer
FileMaker, Inc. - an Apple subsidiary
5201 Patrick Henry Drive
Santa Clara, CA 95054, USA
408-987-3963
[hidden email]
For issues with internal systems, please email: [hidden email]

This email and any attachments may be privileged and may contain confidential information intended only for the recipient(s) named above. Any other distribution, forwarding, copying or disclosure of this message is strictly prohibited. If you have received this email in error, please notify me immediately by telephone or return email, and delete this message from your system.



> On Apr 13, 2017, at 5:50 PM, Stephen Wonfor <[hidden email]> wrote:
>
> Jimmy
>
> Nice advice.  To your last point - are you meaning that in an ESS table of many records you would do a FIND then refresh on that?  And only that data gets refreshed?  Would additional data that met the FIND criteria appear into the found set?
>
> Stephen
>
> ---
>
> Verschlimmbesserung:  A German word for an attempted improvement that just made things worse.
>
>> On Apr 13, 2017, at 5:58 PM, Jimmy D. Jones <[hidden email]> wrote:
>>
>> My mantra is always and every time use Window Refresh Flush ESS Cache when Finding/updating/creating in any ESS table. FMP caches data and unless it requests the new data it doesn't automatically get updated. Because the ESS tables are separate from FMP, access is through the DSN Driver, there is no direct connection between FMP and the ESS tables and no auto update of the FMP cache of data. Clients can create, edit and even delete records and other clients will NOT know about them. The only way FMP knows to retrieve current data is when told to refresh the window, and then it's only the found set of records. When doing a Find only the set of records returned is updated in the FMP cache.
>>
>> BTW, doing a refresh window with an ESS table of a million rows will be slow, how slow is unknowable. I suggest doing a Find for the required records before doing a Refresh.
>>
>> ___________
>> The opinions expressed in this email are my own and do not reflect those of my employer or anyone else.
>> Regards,
>> Ch0c0halic, FileMaker 14 Certified Developer
>> FileMaker Developer Conference 2017
>> July 24-26, 2017 • JW Marriott Desert Ridge, Phoenix, AZ
>> http://www.filemaker.com/learning/devcon/index.html
>>
>>> On Apr 13, 2017, at 2:54 PM, Stephen Wonfor <[hidden email]> wrote:
>>>
>>> Richard
>>>
>>> Another question on this topic.
>>>
>>> Again it involves the 2 MBPros.  Both are on the same db same layout all records showing.  
>>> MB17 shows 406 records, MB15 shows 405.
>>> I added a layout button to CommitRecords(no questions asked).  Still 406 vs 405.
>>> I popped both from Browse to Layout to Browse.  Still 406 to 405.
>>> I execute a FIND on both MBP’s.    Still 406 to 405.
>>> What seems to work is quitting FMP and reconnecting.  Which, while effective, seems kludgy at best.
>>> I gather there is a lag in the process - FMP to ESS.
>>> <Subsequent Discovery> Refresh Window(no questions asked) works!
>>>
>>> So is it your experience that “RefreshWindow” the ticket here?
>>>
>>> It concerns me a bit that if I were reporting on things like TotalRecordCount I’d get different results for different user machines - which I just tested and I do get 406 vs 405.
>>>
>>> Stephen
>>>
>>> ---
>>>
>>> "if you can't talk to your cat about catnip, who will?"
>>>
>>>> On Apr 13, 2017, at 3:07 PM, Richard DeShong <[hidden email]> wrote:
>>>>
>>>> My second point was to try to help you with your statement "This does not really make sense".  It doesn't make sense if you believe that all db servers behave the same way as FMS.  Here are a few points:
>>>>
>>>> 1) In an enterprise sql system, a single table can span multiple db files.  And new records can be written to any of the files (meaning, it's not just old records in file1 and new records in file2, 3, or ...).
>>>>
>>>> 2) Depending on how your connection is configured (at the server level, not the dsn), a single query statement can be executed using a "set" size (similar to how you might get back 10 rcds at a time in a web interface).
>>>>
>>>> 3) Caching can change the retrieve order of records.
>>>>
>>>> These, and more, can combine with a multi-threaded environment to return records in a different order even though the query is the same.
>>>>
>>>> So if you do not specify a sort order on the FMS relationship side, then you will get records in whatever order the sql server gives them to you.  That is, if that's how FMS works with the cached sql data.
>>>>
>>>> Caveat:  It's quite possible that none of this relates to your "silly" (no sense) situation.  Just wanted to point out that sql servers do all sorts of "funny" (not like FMS) stuff.
>>>>
>>>>
>>>> As an aside:  Also note that FMS does *not* return un-sorted results.  (What? But I did not select a sort order in my relationship).  If you don't specify a sort order, then FMS returns the records in creation order.  For speed, most db servers return the records in their "physical" order, and then perform any conditional processing if requested.
>>>>
>>>>
>>>>
>>>>
>>>> On 4/13/2017 1:20 PM, Stephen Wonfor wrote:
>>>>> Richard
>>>>>
>>>>> Thanks.  And yes indeed to your first question - Always Gavan on the MB15 and Carl on the MB17.  The “sort” order for each is the same - no sort order - but the data appears in different orders.
>>>>>
>>>>> Regarding your second thought - might the issue then be the actual MBPros hardware exerting some kind of influence on the communications between MBPro….>FMS15….>ESS……>FMS15….>MBPro?
>>>>>
>>>>> Stephen
>>>>>
>>>>> ---
>>>>>
>>>>> "The real problem is not whether machines think but whether men do." --- B. F. Skinner
>>>>>
>>>>>> On Apr 13, 2017, at 2:13 PM, Richard DeShong <[hidden email]> wrote:
>>>>>>
>>>>>> Are you saying that on the MB15 you always get Gavan as 1st, and on the MB17 you always get Carl?
>>>>>>
>>>>>> If so, then I don't have an answer.
>>>>>>
>>>>>> If you notice that the "unsorted" order of the records is different (note no mention of "always"), then it relates to the source db.   In a SQL db, when you issue a query, there is a "query optimizer" that runs to try to pull records as efficiently as possible.  A primary optimization is to use parallel requests. This means it breaks up your query into multiple processes, running in multiple cpu spaces.  Then it packages up the results and sends it off to your server.
>>>>>>
>>>>>> So if the source is not specifying a sort order as part of the query, then result set can be in different orders.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 4/13/2017 12:12 PM, Stephen Wonfor wrote:
>>>>>>> Hi
>>>>>>>
>>>>>>> I have an 15” MBPro running 10.11.6 and FMPA15.0.3.305 and a 17” MBPro running 10.12.1 and FMPA15.0.3.305.
>>>>>>> Both are logged into the same database (for certain - changes made in one show in the other right away).
>>>>>>> Both on on the same layout.
>>>>>>> There is a simple portal to an ESS Table.  The connection between local and ESS is via a global field - checkbox with values 0 and 1.  This is linked to a field in the ESS table called “fm_viewstate”.  This field allows the user to see external data that has been processed and/or external data that is new (from an online registration system).  The portal is unsorted and unfiltered.
>>>>>>>
>>>>>>> Why am I rambling on about this?
>>>>>>>
>>>>>>> MB15 sees 421 {{RecordNumber}} rows in the portal, with name “Gavan” in row one and “Geoffrey” in row 421.
>>>>>>> MB17 sees 421 {{RecordNumber}} rows in the portal, with name “Carl” in row one and “Geoffrey” in row 421.
>>>>>>> When I go to the FMP layout - both machines - I see that there are 421 records.  Both show as unsorted.
>>>>>>> Yet I see “Carl” as first record on MB17 and I see “Gavan” as first record on MB15.  “Gavan” is record 244 on the MB17.
>>>>>>>
>>>>>>> This does not really make sense.  I wish it did.  Different “unsort” states from machine to machine?  I note that when I sort the portal data occurs in the correct sequence.  When I remove the portal sorting (performance killer) each machine gets a different record in the portal at row 1.
>>>>>>>
>>>>>>>
>>>>>>> Stephen
>>>>>>>
>>>>>>> ----------
>>>>>>>
>>>>>>> "Never lend books -- nobody ever returns them; the only books I have in my library are those which people have lent me." --- Anatole France
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> FMPexperts mailing list
>>>>>>> [hidden email]
>>>>>>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>>>>>> --
>>>>>> Richard DeShong
>>>>>> Logic Tools
>>>>>> 510-642-5123 office
>>>>>> 925-285-1088 cell
>>>>>>
>>>>>> _______________________________________________
>>>>>> FMPexperts mailing list
>>>>>> [hidden email]
>>>>>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>>>>> _______________________________________________
>>>>> FMPexperts mailing list
>>>>> [hidden email]
>>>>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>>>>
>>>> --
>>>> Richard DeShong
>>>> Logic Tools
>>>> 510-642-5123 office
>>>> 925-285-1088 cell
>>>>
>>>> _______________________________________________
>>>> FMPexperts mailing list
>>>> [hidden email]
>>>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>>>
>>> _______________________________________________
>>> FMPexperts mailing list
>>> [hidden email]
>>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>>
>> _______________________________________________
>> FMPexperts mailing list
>> [hidden email]
>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>
> _______________________________________________
> FMPexperts mailing list
> [hidden email]
> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au

_______________________________________________
FMPexperts mailing list
[hidden email]
http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
Reply | Threaded
Open this post in threaded view
|

Re: ESS Puzzle - Approximate Sorting?

Beverly Voth-3
In reply to this post by Richard DeShong

Partitioned on rows 1...100 in one file, rows 101...200 in the next, etc. Or columns 1...10 in one, columns 11...20 in the next? Etc.

(I understand that a Google cannot possibly have every thing in one place.)

 I wanted to make sure you were using the terms correctly. Thanks!

Sent from miPhone

> On Apr 13, 2017, at 9:47 PM, Richard DeShong <[hidden email]> wrote:
>
> And a single table can be partitioned and thus stored in multiple files.
_______________________________________________
FMPexperts mailing list
[hidden email]
http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
Reply | Threaded
Open this post in threaded view
|

Re: ESS Puzzle - Approximate Sorting?

Richard DeShong
My experience, for about 20 yrs as a sys admin of a system at a police
dept, was with a fairly typical sql system that used several primary
files and associated log files.  It was for a fairly small city, so we
never had the need for partitioned tables - I only read about them, and
listened while other sys admins talked about their issues.  So I always
assumed that they were partitioned by rows, not columns.  But columns
could also make sense if there was a set of columns that was rarely used.


On 4/13/2017 7:39 PM, Beverly Voth wrote:

> Partitioned on rows 1...100 in one file, rows 101...200 in the next, etc. Or columns 1...10 in one, columns 11...20 in the next? Etc.
>
> (I understand that a Google cannot possibly have every thing in one place.)
>
>   I wanted to make sure you were using the terms correctly. Thanks!
>
> Sent from miPhone
>
>> On Apr 13, 2017, at 9:47 PM, Richard DeShong <[hidden email]> wrote:
>>
>> And a single table can be partitioned and thus stored in multiple files.
> _______________________________________________
> FMPexperts mailing list
> [hidden email]
> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au

--
Richard DeShong
Logic Tools
510-642-5123 office
925-285-1088 cell

_______________________________________________
FMPexperts mailing list
[hidden email]
http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au