But it is probably causing a few headaches. Note: This change in 3.2 really is a proper approach to databases having mixed types is not proper database structure. If there's no data the field won't take up any room, and only the correct field will show. Then for your mail merge put both the fee and the applicable or not fields next to the Fee prompt. OR do this, which is workable but a bit more complicated. Just put in 0, or just blank, instead of N/A So: in the scenario I outlined you could:
Here's what is in the database, and therefore what a mail merge would have access to. Here's an example of some test and screen shots I took. You can have all text, like N/A, or all numbers like 12, but not both. So your data might look like this:īUT that will not work because mail merges as of 3.2 (possibly earlier) don't like you to mix your types of data in a column. But let's say that sometimes there's no fee, perhaps organizations don't need to pay for cat licenses. Your mail merge document, with the various prompts and the field names, would look kind of like this: You'd put together the spreadsheet data kind of like this, then create a database based on that spreadsheet. Let's say you're putting together a mail merge listing the fees people in the county have to pay for getting their new cat license.
0 kommentar(er)
