Sending selected data to print

[monsnow]

Hello, first post...

Novice user with FM7, I have exhausted my search elsewhere, including my book. I just can't seem to get over this wall, I appreciate your advice.

I have a large database of names that I have created a table, and layouts. I have also created layouts for various letters. My goal is to do a search in the database to pull up a name, transfer that name to a new layout, then print a letter to each name I have found.

To be more specific, my database consists of 160k names/addresses. I find a particular address (a physical street address), enter a search, and the name is found. I then would like to simply hit a button to move this record to a new table. From here I would like to print the letter.

Thank you,

Michael

[MoonShadow]

Hi Michael, welcome to FM Forums!

Are your letter layouts based upon a different table? Even so, if they are related, you can print the entire 'found set.' It would help if you clarified your structure for us.

Normally, you would perform your find and end up with a found set; switch to your letter layout and select Print 'Records being browsed.' Even if your letters are a different table, you can use a Go To Related[] probably. If they are in different tables and not related, you can force a relationship by using a global in your Letters table which you set with the found IDs from your customer table, establishing a relationship from Letters global back to Customers, switching to Letters printing from there.

So, bottom line, how are you structured? We can provide the script to get it done for you. "transfer that name to a new layout" probably isn't necessary - just a script-step to switch layouts (?). I am unsure what tables these layouts are based upon.

[monsnow]

Thanks for your welcome and your reply.

My goal is to keep this all in one database (as that is what I read is best to do). I currently have the the property listings in its own table with 44 fields. I have another table listing the residential characteristics with 76 fields. I also have two more tables with tax information with 23 and 13 fields. In the same file I have created the layouts for the letters. I have not created any other tables to store the found information. I plan on having several found tables depending on the type of information.

When a property is found, I only need to transfer certain fields, not all of them.

One other problem I have is tying the tables together. All 4 tables have a common number, the property id number. I have them linked in the Relationships Graph, but I can't get past that.

Thanks for your time,

Michael

[MoonShadow]

In the same file I have created the layouts for the letters.

What table are your letter layouts based upon? Property Listings?

I have not created any other tables to store the found information. I plan on having several found tables depending on the type of information.

There may be reasons you wish to store your found set but even so, you wouldn't need to create new records but rather just store the 'found' IDs and use another relationship to pull the data back together for you. Could you explain a bit more of what you want to accomplish with this piece?

Your letters (layouts) are simply to display information. It wouldn't be necessary to add data to additional tables to display your 'found' sets. If these tables are all related 1:1 (one property listing to one residential characteristics record & tax record) then just place all associated fields in your letter, find your Property Lists, switch to your letter layouts and print. If they are related 1:n (one-to-many), then you will place your found IDs in a global, use a Go To Related Record (based upon this relationship) and print your letters from the related table. Will there be one letter per Property Listing or what? It might be easier if you can post your file or an example of it.

Apologies for this sounding confusing, but 1) this is a big subject and 2) much depends upon your existing structure.

[monsnow]

No apologies required. Maybe this is why I couldn't figure this out...

The letters will be based upon the found sets, information will be taken from 2 tables, and combined into one (although I could get by with just getting information from one table). I think you are right, you need more detail:

I have purchased the city property information, and converted that information into filemaker. Not easy to do as I went from a text format, into excel, then into filemaker. The major challenge was in excel as the capacity is limited to something like 64,000 lines of data, and I was working with several files each containing over 160,000 lines. But I figured it out and now I have the 4 tables as mentioned in the previous post.

What I do is find properties that require work. I typically have their address, but nothing else. I go into my database, do a quick find, and I have the information that I need. Some of this data I want to forward into a table to keep ongoing - I will keep on mailing a postcard or letter expressing my interest in the property if they ever consider selling. This could be several years.

Some of the data will be temporary, say in a foreclosure circumstance. I might forward the data to a different table, and keep for only a month or so then delete it as their problem gets solved by another method. I currently have a list of about 400 properties that I need to transfer and send letters of interest to. The letter will be the same for each property, except for the address change of course.

After reading your post, it sounds like creating a separate database for my found sets would be wise.

Thanks for your input.

Michael

[MoonShadow]

After reading your post, it sounds like creating a separate database for my found sets would be wise.

Not necessarily, Michael. I would suggest keeping all Property Listings and their Addresses together in the same table. You could add a field flagging the Property Listing disposition (or status), such as Active, Pending, On Hold, Dead, etc. I am going to assume that your letter layouts will be based upon Property Listings.

Perform a find on the address. This will give the found set. Switch to your letter form (layout based upon Property Listings) and print all of them. You may wish to keep an Activity table - one in which you can list things such as:

Record1 -

ActivityDate: 10/1/2004

PropertyID: 376

ActivityType: Mail Letter

ActivityDesc: Mailed opening letter #44

Record2 -

ActivityDate: 10/15/2004

PropertyID; 376

ActivityType: Mail Letter

ActivityDesc: Mailed follow-up letter #46

In this way, you can always re-create exactly the letter you send, without storing any additional information about it. If your tables are properly related, and you base your layout on Property Listing, you can then place fields from your other tables directly on the Letters layout (or use merge fields). A script would assist you in finding the correct records, switching to your specific letter layout, printing all the letters, changing their Property Status to 'Pending' (example), adding a record in Activity showing it was done for each record in your found set, and returning you to your original layout.

The power of relational is NOT having to write the same data over and over in various places. If I'm off base, please explain more. I'll stick in here until I help you. I just don't think you need to write additional data elsewhere, unless it's just a global multiline or something - not when everything is currently related on PropertyID. You already have all the records you need, I believe.

You won't stress FM with your data volume. It can handle it. And if you leave your 'Dead' still in your Property Listings, you might be glad that you don't - again - send another letter to the same property that died several months prior. It will be easy to filter out 'dead' properties from your Finds; it will be harder to try and find properties spread through several tables. If you want a sample demo, I'd put one together for you. It would help to have your specific table/field names (on any critcal fields).

[monsnow]

Again thanks MoonShadow.

Thanks for your offer to create a database, but before that, I will be stubborn and try to learn how to fish first....

Would you mind briefly explaining a solution to these challenges:

1. How does one link the tables together? When I find a property in property listings, I want to go to directly to the characteristics table without retyping the address into that table. I have tried by using a button, but can't get there.

2. Lets say I have one table only, do a search with the address, up pops all the information I need. How do I send this record to another table where I can use this information in letters?

3. This may be trivial, but how much control can you have over content on the web. For instance I can search each property on the city's website as well, I have created a button to automatically open up the page, and copy the parcel number. Then I simply mouse over the search box and hit paste and place the search info in the box. Is it possible to make FM do this automatically? ie. the webpage opens, the parcel number is automatically entered, then automatically opens up the right page. I have tried writing a script, but could not find a way to direct a paste into the page. Again, trivial, but why not?

As a side, I have very big ideas for FM. It seems as if everything I do can be organised with this database tool. I have searched all over the web for sample solutions, and found a few, but I just can't seem to get a grasp as to what FM can do - what the limits are. My book is well written, but doesn't really explain the possibilities ("Learn FileMaker Pro 7" by Jonathan Stars). I am so impressed with the little I have seen so far, that I seriously considered attending the conference this year in Phoenix (with the 3 day training), just to get a big picture look - but decided to hold off until I increased my expertise.

Well now that I got that out...Thanks for your help,

Michael

[MoonShadow]

1. How does one link the tables together?

You indicated that

[monsnow]

Thank you very much.

I will do some experimenting this week as time allows.

Michael