FMPRO-L Archives

October 2010, Week 3

FMPRO-L@LISTSERV.DARTMOUTH.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Joel Bowers <[log in to unmask]>
Reply To:
FileMaker Pro Discussions <[log in to unmask]>
Date:
Tue, 19 Oct 2010 13:36:43 -0600
Content-Type:
text/plain
Parts/Attachments:
text/plain (120 lines)
-- 
Joel Bowers

n. I am also on OS X latest version. In my case the script in the
served file looks for a $path on my local computer (the file is not
open and it was importing all records successfully to the server). I
constructed the $path using the desktop path and a known folder and
filename.  I am not combining old files into a single new file in
general. Just updating (after fixing file references, etc).  So in
general I am importing from a single table old file that has been drag
converted to a new single table file which has been fiddled with.

This is one of my real early projects where my client was using a new
set of clones for each of their new client jobs (only one job open at
a time with a couple common served files linked to each). A real
nightmare to keep updated over the last 18 years. So I am trying to
import sets of files into a version upgrade. They are still on
FileMaker 6.  Hence this is a temporary script. If I cannot get it
working with 11 no problem.  But I was surprised that the script broke
with FileMaker 10 to 11 upgrade.  It still works fine in 10.

Cheers,
Joel

On Tue, Oct 19, 2010 at 12:56 PM, Stephen Wonfor <[log in to unmask]> wrote:
> Joel
>
> Just did some fiddling.  Local file on desktop, same file on server.  When I set this $Path = "fmnet:/192.168.0.229/"& Get ( FileName )" the import works ok.  I confirmed that I was seeing the right files by adding a table called "Server" on the hosted db.
>
> Stephen
>
> ----
>
> WIRE  WHEEL:  Cleans paint off bolts and then throws them somewhere under the workbench with the speed of light. Also removes fingerprints and hard-earned calluses from fingers in about the time it takes you to say, "Oh, s---!"  (---Attributed to the list at http://techtalk.parts-express.com/; Also claimed by others...)
>
> On Oct 19, 2010, at 12:18 PM, Joel Bowers wrote:
>
>> I have an import script that uses a $path to a local copy with the same file
>> name to import into a served copy of a file. Designed and working in version
>> 10. Version 11 seems to have broken the ability to import from a file with
>> the same name via this method. I have just used version 10 instead of
>> figuring out if there is a way to make it work in v11.
>>
>> Cheers,
>> Joel Bowers
>>
>> On Tue, Oct 19, 2010 at 11:39 AM, Stephen Wonfor <[log in to unmask]>wrote:
>>
>>> Sue
>>>
>>> Just took a look with FMP11A from one database to another.  The import
>>> shows the found set (15 of 2,514) when I load from a base table in one file
>>> into a base table in the other.
>>> I do Anchor Buoy design (www.kevinfrank.com/anchor-buoy.htm or
>>> http://sixfriedrice.com/wp/six-fried-rice-methodology-part-2-anchor-buoy-and-data-structures/)
>>> so I always have base tables, they are the only tables I use for the context
>>> for a layout.  When I do a find on a layout it is inherently in the context
>>> of a base table - thus it honours the data in that table and is not a "view"
>>> of the data via a relationship.
>>> The key might be in the context of the layouts.  If your layout is based on
>>> a non-base table (a Buoy in the AB design) I think it may be possible to not
>>> get the found set correctly.
>>> If your design is not AB you may need to base your imports from purpose
>>> build layouts that rest on a context defined by a specialty base table. eg.
>>> You might have a Contacts table but you would use ContactsExport base table
>>> to do finds upon.
>>>
>>> I do a lot of inter-db imports this way.
>>>
>>> If that still fails you might consider using a "one-time" key to write data
>>> from one db table to another via script.
>>> eg. Set Get(CurrentTimeStamp) into a global and add a $Counter - eg.
>>> "10/29/2010 17:00:32 Count 1".
>>> You would loop through the found set incrementing $Counter each time and
>>> update the global (with a Commit).  You'd have a join between tables that
>>> allowed creation of related records.
>>> This works well - the only persistent issue is auto-enters in the receiving
>>> table (they can be handled but you need to be aware of them).
>>>
>>> Stephen
>>>
>>> ----------
>>>
>>> "The physicist's greatest tool is his wastebasket."    — Albert Einstein
>>>
>>> On Oct 19, 2010, at 11:13 AM, Sue wrote:
>>>
>>>> I am having a hard time getting Filemaker to import just the FOUND set of
>>> records from one Filemaker table to another FM table in a different File.  I
>>> want just 7 out of 126 records, so my script opens the first file and runs a
>>> Find script that locates the desired 7 records in the first file.  Then my
>>> script (which is run from the second file) imports records from that table
>>> to the new table in the second file.
>>>>
>>>> Only one window is open in the first file and only the 7 records I want
>>> are found and showing in that window.  Yet I still get 126 records imported
>>> to the second file.
>>>>
>>>> Arg.  What do I need to change to get this to work right? I am sure I
>>> have been able to do this sort of thing in the past.  What am I doing
>>> differently, or what do I have set wrong?
>>>>
>>>> (Just upgraded to FM 11, but I don't think that is the problem.)
>>>>
>>>> Thanks for any help!
>>>>
>>>> Sue
>>>
>>
>>
>>
>> --
>> Joel Bowers
>



-- 
Joel Bowers

ATOM RSS1 RSS2