Merge Fields with tab

[jimlongo]

Hi, I have a text block with lines containing merge fields

<> <>

<> <>

The documentation states

You can insert punctuation, spaces, line breaks, and text between merge fields as needed.

If I put spaces they shrink as they should, However if I put a tab stop between the items on each line they no longer shrink.

Is there a solution to this?

Thanks,

jim

[comment]

Why aren't you reporting from the child table (assuming there is a child table)?

[jimlongo]

Hi Michael, I'm not sure of your question. The calculation is working just fine, it's only the layout that is a problem.

[bruceR]

No, you do not have a layout problem.

You have a database structure problem.

Almost anytime you see someField1; someField2; someField3 it is because the database is not properly set up with a child table. That is definitely the case here; and (as usual) the reporting would be easier if it were set up properly.

[comment]

Tabs are characters and if a line contains one, it will not slide up. However, the real issue is elsewhere. If you report from a child table, where the body part contains:

<> [color:gray]tab <>

there will be no problem to solve.

[jimlongo]

Thanks, I'm not being argumentative and excuse me if my screenshot was misleading. The first screenshot was in layout mode.

The result of that layout in Browse or Preview is

My question is why aren't the lines sliding up? It seems to be a result of using the tab space in the layout.

Forgive me if your answer remains the same . . . I can't find the words "child table" anywhere in the documentation.

Thanks,

jim

[bruceR]

It's a very basic and fundamental concept of databases. You have "parent" and "child" tables linked by key fields, most commonly to set up one-to-many relations exactly as your are doing here. Except that you are thinking like a spreadsheet instead of like a database.

Edited November 30, 2010 by Guest

[jimlongo]

I'm obviously very confused.

The Layout Setup>General> Show records from>Master ID (parent table?).

The fields I have in this layout come from that table.

Those fields are calculations that derive their data from Members t_ID and Transactions t_ID (related child tables?).

Those calculations seem to return the correct data.

Why is that an issue in the layout?

Thanks again,

jim

[comment]

Those calculations seem to return the correct data.

Yes, but they are redundant. You could achieve the same result by placing a portal on the layout, or - preferably - doing the report from one of the child tables (probably the Members table in this case).

why aren't the lines sliding up?

Because they are not empty; they contain a tab and a carriage return. You COULD use a calculation field to calculate the entire text block, using Case ( not IsEmpty ( ... ) ; ... ) - but again, this would be just spending more efforts to solve a problem which shouldn't exist in the first place.

[jimlongo]

Yes, but they are redundant. You could achieve the same result by placing a portal on the layout, or - preferably - doing the report from one of the child tables (probably the Members table in this case).

So I will start a report that has LayoutSetup>General>Show records from "Members"

I'll still in some places on this report need to use data from the Master ID table and the Transactions table.

Won't I run into the same situation?

Thanks for your patience.

[comment]

So I will start a report that has LayoutSetup>General>Show records from "Members"

I'll still in some places on this report need to use data from the Master ID table and the Transactions table.

Won't I run into the same situation?

It depends on what exactly your report contains. As a rule of thumb, you would produce the report from the most "atomic" table you draw data from. So if your report contains data from the Transactions table - either detailed or summarized - it should be produced from there, with sub-summary parts for the higher-up tables.

I am not sure what your "Master" table is about, though. I presume that in the Transactions table, each record is a transaction, and in the Members table, each record represents a member. What does a record in the Master table stand for?

[jimlongo]

We have 3 types of membership.

There are "adults", "juniors" or combinations of those categories which comprise a "family".

The Master table is mainly the address that ties together all the members in that household no matter which category they belong to. It's also the main layout that has a portal with Members and Transactions.

So 1 Master record for SMITH is related to all the smith Members and all their transactions.

Does that make any sense?

Edited November 30, 2010 by Guest

[comment]

Yes, except the name. Why not call it Households or Families?

[jimlongo]

That would be the easy.

In this case I want to create a report for each Family,

Wouldn't I use Families as the parent table

Layout Setup>General>Show records from Families

and get data using information from Members_families (names, date of birth, etc., ) and Transactions_families (date,price,category, etc., ) ??

[comment]

No, exactly the opposite: the layout should be based on the Transactions table. Information about individual transaction goes into the body part. Members data will be in a sub-summary by MemberID part, and information about the family in a sub-summary by FamilyD part.

BTW, I don't see why your RG couldn't be simply:

Families -< Members -< Transactions

EDIT:

Unless I am misunderstanding and the transactions are related to families directly, and not associated with a particular member.

Edited November 30, 2010 by Guest

[jimlongo]

Okay I'm going to work on that . . . I'll be back next week.

Thanks so much.

jim

[jimlongo]

No, exactly the opposite: the layout should be based on the Transactions table. Information about individual transaction goes into the body part. Members data will be in a sub-summary by MemberID part, and information about the family in a sub-summary by FamilyD part.

BTW, I don't see why your RG couldn't be simply:

Families -< Members -< Transactions

EDIT:

Unless I am misunderstanding and the transactions are related to families directly, and not associated with a particular member.

Transactions are related to Members and grouped together for each Family. In other words each Family has a bunch of transactions, and each may pertain to different Members of the Family.

My main layout is the Families table with a portal to the Members table and another portal to the Transactions.

I've changed the relationship graph as you suggested, that all works fine.

But if I want to send a report for each Family don't I have to base this on the Families table? If I set it up to be based on Members I get a report for each member, or even more if I use Transactions as the parent table. (eg., 10 Families, 30 Members, 80 Transactions)

[jimlongo]

After more tutorials I think maybe I should revisit the structure of this database, especially since it's veered far off topic from where it started

. . . I've started a thread to do that here

[comment]

Transactions are related to Members and grouped together for each Family. In other words each Family has a bunch of transactions, and each may pertain to different Members of the Family.

But that's not what your graph shows. The relationship between Members and Transactions should be based on matching MemberID, not Family ID - otherwise no transaction is related to a specific family member.

But if I want to send a report for each Family don't I have to base this on the Families table?

No, but your layout needs to have a sub-summary by FamilyID part. If you like, you can set this part to cause a page break, so that you can easily separate the reports for each family.