As you can see, longer content – such as very long names – don’t fit within the allotted space.  Ordinarily you could just set anchors to have the field grow to the right, but in this particular use case, we already have one anchored field – Notes – set to grow rightward.

In this type of situation, I can call on Conditional Formatting to save the day.  I actually got the inspiration for this one by using the calculator on my iPod Touch.  Type a number and it appears in the calculator, pretty large.  If you keep typing digits, then number gets smaller to fit in the area of the display.   Brilliant!

How can we do this with conditional formatting?  It’s relatively simple; the technique involves setting multiple conditions to a format based on Length().  See the screenshot below:

The conditions are evaluated in the order they are listed, so as the length of the contents of the field gets longer, I apply a smaller and smaller font size.  In addition I like to use the ‘Condense’ feature.  This writes the characters just bit closer than normal.

The final result is shown below.

This technique can be used on list views and also on printed reports.  It is so natural that your users won’t even know you are doing anything sophisticated!

There has been a lot of buzz floating around the web regarding the content management system called Drupal.  Over the next couple of weeks I am going to investigate this growing platform from the perspective of a FileMaker developer.  Drupal is not a Filemaker replacement, but there are definite use cases where Drupal is an ideal content management choice. Instead of my regular posts about filemaker techniques, I will explore how Drupal is similar and different from my platform of choice.  With a nod to a good movie about exploring other cultures (Crossing Delancey) I am calling this series Crossing Drupal.

In this first installment I would like to simply lay out some simple terms, so we can all speak the same language.  A rosetta stone if you will.

First, let’s talk about what Drupal is.

What exactly is Drupal?

Drupal is a framework that lets you build a web site with dynamic content.  The web site happens to be built using PHP and the database is MySQL.  But you don’t really need to know that to get off the ground.  Drupal, like its cousin WordPress, is a tool to build websites.

Im not a PHP or SQL expert how can I understand how to use this tool?

As a FileMaker developer, I typically think in terms of Tables, Fields, Relationships and Layouts.  Drupal has some of these things but they are not named the same.  Let’s mark out some places where these FileMaker terms have analogues in Drupal.

Drupal is a essentially a content management platform.  Content comes in different types.  A content type is similar to a FileMaker table.  On the default Drupal installation there are two content types: Pages and Stories.

Let’s take the default installation as an example.  You can think of this set of two content types as a two table file, in which each table contains two fields: title and body.  It’s possible to add more fields through the CCK (Core Construction Kit) module, but you always have the two ‘default’ fields to start with.  You can also add more Content Types.  Need to track Authors?  Make it a Content Type.  You can also enable a number of basic definedContent Types (Forum, Poll, Book Page, Comment, Blog Entry) that are disabled with the default install.. Just like using FileMaker, the purpose of the database will dictate the form that the database takes.  A Drupal site will be dependent on the purpose.  For a company that sells books, you might see the following content types:

• Books
• Authors
• Salespersons Blogs

For a community group you might see these content types:

• Members
• Committees
• Teams
• Group Blog (i.e. What’s New)
• Committee Minutes

The big message here is “Content Type” is like a FileMaker Table – at least conceptually. Put in more generic ERD terms, Content Types are Entities. Don’t be misled by this, however; if you look at the back end database a Drupal site creates, you will not find a Books table or a Members table.  All of this is abstracted away.  It is important to use the Drupal Tools provided, until you know what you are doing.

Next Steps

Over the next couple of entries I am going to demonstrate the power of this platform by building a simple web site for a fictitious store.  Our web site will have products listed and a Blog section.  The features include:

• Users of the site will be able to browse and search a product catalog.
• Users of the site will be able to read a blog where specific products are highlighted.

Once this is built I will show how to make simple links from the ‘public facing’ web site to a ‘back end’ FileMaker database.  The database will pull in product info from the FileMaker database.

Keep an eye on this blog for future installments!

Recently I was on a family trip to Pittsburgh.  We were walking around the campus of Carnegie Mellon and I saw this memorial brick;

It got me to thinking about some of the monster databases that I have had to take over for clients.  When I take over a project, often I am spending a great deal of time just trying to figure out what the developer was trying to do.

Our earlier posts on this blog are generally concerned with improving the user experience(better printing workflow) or getting more out of your data (One Report two sets of summarized data).  Today I would like to return to that lowly person, the developer.  Anything that I can do that can make my job easier will make be a better developer and ultimately make my customers happier.  Or as my grandfather would say to my grandmother, “What would you do if I got hit by a bus?”

When I create a new script, I always try to write the outline in the comments before I add any code.  By writing the comments FIRST, I am sure that they are there when I am done the script, saving me from having to go back and add it to the code.

The hardest part is knowing what to comment and what not to.  I have seen developers that comment almost every line, and some who don’t use comments at all.  The trick is to comment the broad strokes, I like to think of them as the ‘Turns in the Story’.  You want to comment those things that you think you are most likely to forget.  Also those things that are not obvious.

My rule of thumb is to try to always start with the basic pattern.  Each script is written in the following pattern

1. Permission. Can this script be performed at all.  Check for User status, appropriate setting, appropriate record.  Examples, only Super Users can perform this script.  This script can only be run on a particular layout, or this script can only be done on a record with certain fields filled in.
2. The body.  This is the heart of the script.  Make the report, make the changes etc.
3. Cleanup.  Be a good Boy Scout.  Leave only footprints and take only pictures.  Make sure you are on the right layout, the right found set, the curser is the right place.  And any globals used are reset.

With this in mind, almost every script I write starts with 4 lines.

With this as a starting point I can begin to fill in either write the script from here or start putting in some comments.

Here is an example of a complete script.

Note that by just focusing in on the comments, in bold, you get the idea of what the script is doing.

Obviously not all scripts can fall neatly into this structure, but you will be surprised at the number of scripts that can.  Using this as a starting point will also help you to keep your scripts understandable.  Another example.  Right after the Permission section, just after the ‘Done Error Trapping’ comment in my scripts.  I will almost always set all the globals and variables I will need for the script.  Doing this task at this point assures I will always know where to look the next time I visit the script.  If I am feeling partially generous, I will even put in a comment for the exceptions.  That is any variables that can’t be set at the beginning.  For example a variable that can’t be defined until the user answers a dialog box.

The idea is to make sure you always know where to go to find out what a script is doing.  This will make it easier for you to trouble shoot any problems months after you have forgotten why you wrote the script in that particular way.  Using this framework will also help you identify things that are out of the ordinary.  These are the things that will most likely need a comment.

- Jerry Salem

five different types of charts to your FileMaker layouts including vertical and horizontal bar charts, line charts, area charts, and pie charts. At IT Solutions, we’re very excited at the ease at which we’ve been able to use the new FileMaker Charts feature to build very rich dashboards in existing FileMaker solutions.

What data can you chart?

Any FileMaker data can be represented using one of the five chart types as long as the data can be represented in a data series. The data series is simply a list of value pairs that represent the two axes on your chart. For example, if you were charting total sales over four quarters, your data series would include four value pairs: Q1 $23,000, Q2 $18,000, Q3 $28,000, and Q4 $24,000. If these values were represented on a line chart, the left side of each pair would make up the X-axis or bottom of the chart and the dollar amounts would make up the Y-axis or left side of the chart.

FileMaker offers several different ways to access data in a series. You can use data from related fields, data from fields in the current record, or data from fields in the current found set. The third option can be extended to include summarized data (the groupings on a summary report) when the data is sorted appropriately.

Transforming data into the appropriate form for a desired chart can be tricky. Start with the end in mind by considering what the data series should look like based on your goals with the chart and figure out where the chart will be located (on which layout in your database). Based on that layout, first make sure you can see the raw data in the correct form. If you can, then the chart will be a breeze.

Dashboards

A dashboard is an overview of the data in your system, often originating from different data sources, for the purpose of seeing a bird’s eye view of your organization. Unlike a single chart on a layout or report, dashboards are often a collection of different charts and/or lists of data that can come from a variety of sources, either different databases, or different tables within the same database. As a result, one dashboard may utilize different types of charts that access data from different sources in different ways.

This is an example of a four-panel dashboard that has been added to a simple project tracker solution built exclusively with the FileMaker Chart tools. Each chart is based on data from different tables in the database and the layout is based on a “system” table. None of the data represented on the dashboard is stored in the system table. Different techniques are used to transform the data from each source into the proper data series structure for each chart. Together the charts make up a high level overview of four different parts of the system.

The next example is a dashboard from our own internal project management solution. This dashboard mixes charts and data elements to create a robust overview of our open projects. The bottom of the dashboard is dynamic; a project is selected in the drop down and the data elements and four charts are updated to show only data pertaining to that project.

Conclusion

FileMaker Charts is an exciting new feature that allows developers to take FileMaker solutions to a whole new level, without the use of any third party tools. All FileMaker Charts are fully customizable to match the look and feel of an existing solution. By combining data and charts from a variety of data sources, robust and comprehensive dashboards can provide an executive overview of an entire organization on one FileMaker layout.

If you have any questions about FileMaker Charts or dashboards and would like more information on how we can add dashboards to your solutions, feel free to contact Jason Mundok at jason.mundok@itsolutions-inc.com.

If you’re a dedicated FileMaker enthusiast, the place to be this August is San Diego, CA for the annual FileMaker Developers Conference, also known as DevCon. Each year, FileMaker developers from around the globe gather for the four-day conference to learn about all things FileMaker, connect and network with other FileMaker enthusiasts, and discover new FileMaker related products and services at the product showcase.

Starting with preconference sessions on Sunday, the week is full of general sessions, workshops, and panels where you can learn about and discuss the technical side of FileMaker, development best practices, or how to manage FileMaker projects or an entire FileMaker business. This year will also feature an entire track of sessions for certification preparation that are based on the FileMaker Training Series. Sunday evening will include a keynote address where FileMaker executives will showcase FileMaker technologies for today and beyond.

To assist with networking, evening events will include a welcome reception following the keynote address on Sunday, a special awards dinner for FileMaker Business Alliance members on Monday evening, and a dinner for all conference attendees on Tuesday evening aboard the USS Midway. DevCon is the ultimate place to meet and discuss FileMaker with like-minded enthusiasts and members of FileMaker, Inc.’s staff.

IT Solutions’ Jason Mundok will be presenting two sessions and moderating a panel at this year’s DevCon. During the PreCon sessions on Sunday, August 15, Jason will be presenting “Managing FileMaker Projects Using Agile Methodologies”. In this session, Jason will explain the Agile methodology used at IT Solutions to manage all FileMaker development projects and how FileMaker is the perfect platform for this flexible and iterative approach. On Wednesday, August 18, Jason will be presenting “Streamlining Workflow with FileMaker Pro” which will focus on a few features currently being used in FileMaker workflow solutions such as RSS feeds based on FileMaker data, text messaging from FileMaker, and using the FileMaker Charts tool to build an executive dashboard. Later that afternoon Jason will be moderating a panel of FileMaker industry experts who will be discussing training and professional development tips for developers to stay on top of their game.

We’re also going to be planning an IT Solutions/Philly FileMaker meetup at this year’s DevCon. If you’re from the Philadelphia area or connected to the IT Solutions network and would like to meetup at the conference please contact Colin Keefe directly at colin.keefe@itsolutions-inc.com to get more details and let us know to look for you. We hope to see you in San Diego!

If you have any questions about DevCon 2010 or would like more information, feel free to contact Jason Mundok at jason.mundok@itsolutions-inc.com. Visit the official DevCon website at http://www.filemaker.com/developers/devcon/.

Other exciting new features in FileMaker 11 include:

• Enhanced Table View for quick spreadsheet like reporting.
• Snapshot Links to preserve a found set of records including layout and sort order, or to email a link to a specific set of records in the database.
• Recurring Import to automate imports for an Excel spreadsheet or text file every time you open your database or visit a particular layout.
• Quick Find allows a browser-like search for data across all fields on your layout without leaving browse mode.
• Inspector takes layout mode to a whole new level combining all of your favorite design tools in one efficient palette.

For more about FileMaker 11 visit www.filemaker.com.

During the summer of 2009, three top names in the FileMaker community, Andy Gaunt (FMPug), John Sindelar (SeedCode), and Ernest Koe (Proof), thought it might be cool to gather a bunch of FileMaker minds together in a hotel with one goal: share. The idea was to share ideas, techniques, and best practices around all things FileMaker. There would be no commercial advantages, no booths, no ads, and most importantly, no registration fee for anyone who wanted to attend. Sounds like an unconference!

With no budget to speak of, they turned to the free side of the web and social networking giants like Twitter and Facebook, along with free event planning resources, to handle what little organization they would actually need. In a recent interview with Ernest Koe and John Sindelar, Koe explained that at a minimum they just needed to pick a time and place. And so they did. The first Pause On Error unconference was scheduled for July 16 and 17, 2009 at the Ace Hotel in New York City. Approximately 60 or 70 people from around the country crammed into attendees’ suites to speak, listen, and share. It was a smashing success and word spread around the FileMaker community with lightning speed. After the dust settled in New York, Molly Connolly (Thorsen Consulting) joined the original three and formed the Pause On Error steering committee. They soon set their sights on the west coast.

Pause II was held at the Ace Hotel in Portland, OR on January 21 and 22, 2010. How could this sophomore effort prove to be better than its predecessor?  Koe explained that Portland had the benefit of following New York’s template. Sindelar chimed in that there were a lot of philosophical questions being asked before New York.  Those questions had answers by the time Portland was being planned. Having a baseline from which to work made planning quite a bit easier. Also the dates were announced with more advanced notice for anyone planning to travel.

I was fortunate to attend the first day of Pause On Error and was blown away by the high level of enthusiasm, collaboration, and content. Over one hundred people descended on the Ace in Portland and to the dismay of the steering committee, they had to cut off registration a few weeks before the event in fear of overcrowding the accommodations. The hotel was at capacity and some late registrants had to stay elsewhere. Sessions were held in four suites on the fourth floor. In the more popular sessions, seating on couches and chairs went fast, but attendees found whatever space they could, including the bathrooms and the beds. In the grass roots spirit of Pause On Error, sessions were geared more toward discussion and less toward a one-way dissemination of information. Presenters simply planted seeds and then opened up the floor and let the attendees guide the conversations.

In the evenings, without any kind of official events planned, attendees formed ad hoc social groups and explored the neighborhood in search of local cuisine, or simply gathered for continued conversation at the hotel’s pub and coffee shop. The night before Pause, I found myself with a seemingly random crew of eight developers from around the country sampling some fine seafood at a restaurant a block from the hotel. Then after a full day of sessions I spent hours catching up with friends, old and new, at the hotel pub over some fine local brew.

In the true spirit of a grass roots gathering, everyone contributed to the energy of the sessions by donating gear and helping run tech. In New York, the sessions had been streamed using Ustream, the free web broadcasting service. While the audio transmissions were adequate, the video quality was very poor. For Pause in Portland, the steering committee decided to record the sessions in HD with an assortment of borrowed cameras and high quality microphones. Each session had volunteers running the a/v equipment while the presenters recorded their screens. In the weeks following Pause, live video and slides will be merged for a full quality broadcast for anyone to experience. According to Sindelar, Pause is still being broadcasted, just with a little delay.

I attended two sessions about testing and development practices with Gerald Chang and Vince Mennano (Beezwax). While the sessions weren’t connected, there was some overlap in content. Gerald focused his session on the development and testing environment at his company where he’s an in-house developer. Vince expanded on the idea of development environments with a review of upgrade deployment options and an overview of some migration techniques that he has been working on.

In the afternoon I attended a packed session by Kirk Bowman (Mighty Data) on value pricing. The dialog was very lively as Kirk laid out the basis for Mighty Data’s migration from hourly billing to value pricing. It was obvious that the community is very interested in finding out more about this fresh approach to pricing projects. So obvious that the only free space I could find to sit during the talk was in the bathroom with six or seven other folks trying to squeeze in!

Jason Young (Mighty Data) presented his findings from some recent performance testing that he’s been doing to found out the fastest ways to set and get values from across large data sets. Did you know that looping through records is significantly faster on a layout set to form view, and that table view is significantly slower than both list and form? Another fascinating insight from Jason’s presentation had to do with getting data. When using a script, building a list of values from a field across a large found set is faster when navigating to each record in a loop and setting a field, as opposed to using a function like Get Nth Record. But as Jason pointed out, the List function (when applicable) still rules for getting data when it comes to performance!

Finally, my day ended in a session with discussion facilitated by John Sindelar (Seed Code) that focused on the FileMaker development community itself. It was obvious what was important to this segment of the community: we need to unify and become much stronger from a “big picture” perspective and not get hung up on the little things. We need standards, big picture conceptual standards, not more arguments over naming conventions. This end-of-day session was packed and encompassed all that I believe Pause On Error is growing to represent. It is a movement that is helping a community of developers find its way organically through enthusiasm, through the collaboration of people willing to volunteer time and resources to contribute to a higher cause, and through and extremely talented pool of resources that can bring a high level of content to the table so we all can become smarter and better at what we do.

I asked Ernest and John about the future. I asked them what is next for Pause On Error. Fortunately for the FileMaker community the answer wasn’t “nothing”. But we’ll have to wait for the dust to settle over Portland before we get to pause our day-to-day lives and book the next plane ticket. My advice is to get in early because it’s not going to get any easier to land the coveted spot on the couch at Pause III.

- Jason Mundok (IT Solutions)

Automation with FileMaker Server Scheduler

For many years automating tasks in a database hosted by FileMaker Server required a “robot” computer that used its operating system’s scheduler to open a dummy FileMaker database file at a particular time. The dummy database would then connect to a hosted database, trigger a FileMaker script, and then close FileMaker Pro. Robot machines worked for the most part, but there were many factors that could go wrong and often did. For example, the robot machine had to be on and running properly with an active network connection to the server.

FileMaker Server 9 introduced a feature that allowed FileMaker scripts to be scheduled in the FileMaker Server Admin Console. Scripts could run automatically without having a copy of FileMaker Pro running on the server or on a robot computer. This was a major step toward reliable automation and the end of robot computers.

Unfortunately, because the database wasn’t open in FileMaker Pro, not all script steps could be run on the server. FileMaker Server 10 has taken the script scheduling feature further by allowing server compatibility for many more script steps. Most importantly, FileMaker Server 10 allows for importing and exporting of data on the server. In this article, all examples of automation are based on an environment running FileMaker Pro 10 and FileMaker Server 10.

What would I want to automate?

Over the years IT Solutions has set up automation on many FileMaker systems, and for many different reasons. Most commonly, automation is used to create a set of records in bulk at a particular point in time so that they will be waiting when a user logs in and needs to use them. An example of this kind of automation is timesheet records for employees. On a particular day and time, such as Sunday evening or early Monday morning, timesheet records are created for all active employees. Another example is the creation of attendance records for a school. When a teacher logs in to take attendance, records for the day are already created for the teacher’s current class roster. All he or she has to do is mark the records for absent students.

Another kind of automation we are often asked to create has to do with updating statuses. System dashboards and classroom assignments are examples of statuses within a system that need updated. System dashboards often collect data elements from different sources within the database and then display them in one consolidated graphical overview. Updating dashboards a few times a day is often enough to provide a bird’s eye view of the organization.

In a school setting, students may be assigned to certain classrooms or programs for a particular amount of time. By allowing teachers to enter both start and end dates for those assignments, the system can update a student’s status automatically. Each day a server-scheduled script can run on all classroom assignments and set them to active or inactive based on the dates entered in the system. Additionally, the scripts can add or remove them from the student’s schedule, which may be stored in a separate part of the system.

A third type of automation deals with system integration. Certain types of SQL databases can have a real time connection with FileMaker using the ESS (external SQL source) feature. For systems that are not ESS compatible, integration scripts can be scheduled to run as often as required by an organization’s business rules. For example, when doing integration with an accounting package, such as QuickBooks, it is often required to batch post customer and invoice records at the end, or throughout, each business day. Likewise, balances may need to be pulled from the accounting package back into a FileMaker. These processes can be scheduled to occur as often as needed to allow for accurate representation of data in both systems.

Another example of automation for system integration is importing and exporting data to and from databases to maintain a single authoritative data source for an organization’s collective system. For example, FileMaker cannot establish a real time connection with SAP systems, but FileMaker Server 10 introduced the ability import data from an external file using a scheduled script, so long as it is located in a particular directory on the host server. So, we can schedule the operating system to copy a file into a particular location, and then schedule FileMaker Server to import and update data from that file in a hosted database. This keeps SAP as the authoritative source for certain data, but allows FileMaker users access to use that data at will. All of this can happen in the middle of the night or at particular time intervals without the need for user interaction.

Limitations

How can you tell whether or not a script step will work properly if it is included in a script that is scheduled to run on the server? The Manage Scripts tool in FileMaker Pro 10 offers a convenient compatibility checker located in the bottom left corner of the Edit Script window when modifying or building a script. By default the compatibility checker is set to “Client” which includes all script steps. Changing that value to “Server” or “Web Publishing” shows which script steps are not compatible to each respective environment by changing the color of the script step from black to gray.

Why are some script steps not compatible when running on FileMaker Server? When a script is running on FileMaker Server, no instance of the database will be opened in FileMaker Pro. This prevents certain kinds of actions from being possible. For example, layout dependent script steps, such as adjusting windows, showing a custom dialog box, or entering preview mode, will not be compatible because there is not layout available to the script.

Developers should use caution to only schedule scripts with 100% compatible steps. If the FileMaker Server attempts to run a scheduled script and it encounters an incompatible script step, the script will be aborted and an error will be written to the server log.

If you have any questions about automating your FileMaker solution using FileMaker Server script automation, please do not hesitate to contact me, Jason Mundok, at jason.mundok@itsolutions-inc.com or 866.PICK.ITS.

When FileMaker and QuickBooks integration makes sense

There are two common reasons to choose to integrate FileMaker with QuickBooks, rather than using one or the other exclusively. The first is simply when source data need to be shared between two systems, and the second is when a QuickBooks feature, such as invoicing, needs to be expanded upon and customized to suit the needs of the business.

Sharing data between systems prevents double-entry and the inevitable problems of keeping to separate systems in sync manually. As an example, FileMaker may be used to manage certain parts of a business that QuickBooks simply doesn’t deal with, like a manufacturing process or project management. If some of the same data are used by both systems, such as employee info or vendor records, then either system can be the data source, as long as they can be synchronized often enough to remain accurate.

No matter how robust QuickBooks is, it is still designed for thousands of businesses and therefore cannot completely serve the nuances of individual companies. Many small businesses serve niche markets, offering products and services that are rare or unique, using processes that are different from a typical approach. Often times these niche processes cannot be worked around. Since FileMaker is completely customizable, we can create a system needed to deal with the more complex pieces of the puzzle, and then push the results to QuickBooks in a way that it understands. Then we can let QuickBooks take care of the other pieces of the process that are standard.

A common example of this second reason for integrating QuickBooks and FileMaker is invoicing. If a business needs to invoice in a way that isn’t native to QuickBooks, we can create and produce invoices in FileMaker, roll up and push the invoice data to QuickBooks and allow the remainder of the receivable process to happen there. We can even pull back invoice balances so FileMaker users can check the status of an invoice from inside FileMaker.

How does it work?

Over the years, we’ve used all available means to integrate FileMaker and QuickBooks for our clients. We have found 123sync from SolutionsMakers, Inc. (http://www.solutionmakers.com) to be the easiest and most cost effective way to get the job done. 123sync uses a plug-in in the background to actually push and pull data between systems, but the heavy lifting is already taken care of with a pair of FileMaker “sync” files that are hosted on the same FileMaker server as your solution. First we’ll look at how it works from the FileMaker-to-QuickBooks perspective.

Throughout the work day, records are entered and updated in FileMaker. For example, a user may enter a new customer record, update a customer’s contact information, or create a new invoice for a customer. When completed, these FileMaker records are ready to be sent over to 123sync. This process can either be manual or in a scheduled batch. The IDs are copied into one of 123sync’s FileMaker files and staged. Again, either manually or in a batch at a particular time interval, the records are posted to QuickBooks by 123sync.

Why the extra step by staging the records in 123sync instead of just sending them straight to QuickBooks? 123sync is designed to be the translator between your FileMaker solution and QuickBooks and contains all of the rules necessary for seamless integration. QuickBooks expects data to be posted in a certain order and has many rules to guarantee good data is coming in. 123sync understands those rules so only good data gets into QuickBooks and all records are posted in the correct order. If a FileMaker record breaks one of QuickBooks rules, 123sync logs the error and provides feedback on what went wrong so you fix the problem and guarantee that only good data end up in QuickBooks.

From the other direction, 123sync pulls list data, such as vendors, terms, or shipping methods, from QuickBooks into the FileMaker sync file. Because that data are then stored in FileMaker tables, we can fully integrate with your FileMaker system. We can use the QuickBooks data to drive the value lists in FileMaker to make sure you don’t have to maintain those lists in more than one place. The hardest part is often deciding in which system it makes the most sense to store and maintain the data.

The best thing about 123sync is that the FileMaker sync file is customizable. All of the 123sync processes can be performed manually or automatically as necessary to fit within your business’s workflow. With new features in FileMaker 10, such as script triggers and script timers, we can trigger 123sync functionality from your existing FileMaker solution and let it do all of the heavy lifting in the background. On the other hand, if getting up and running quickly is the priority, the sync file has an easy-to-understand user interface that you can start using right “out of the box”.

If you have any questions about integrating your FileMaker solution with QuickBooks, please do not hesitate to contact me at jason.mundok@itsolutions-inc.com or 866.PICK.ITS

Saving records as a PDF

From the File menu, click on the “Save/Send Records As” sub-menu and choose the “PDF…” option. You will be prompted to enter a file name and location where you want the PDF to be saved. There are also some other options that should be noted which are similar to those you can choose when printing. Keep in mind that the PDF will be formatted exactly as your FileMaker layout is formatted and will include all layout elements within the page margin boundaries. You can choose to save the following sets of records:

• Records being browsed – if the layout is set to List view, the PDF will contain a seamless list of records, but if it is set to Form view a new page within the PDF will be created for each record.
• Current record – only the currently displayed record will appear on the PDF. While this is not a desired behavior for a List view, for Form view layouts you may only want the current record to appear as a single page in the PDF.
• Blank record – this option is for creating a PDF that is formatted like the FileMaker layout, but doesn’t contain any data. This option is excellent for printing blank forms that need to be mailed or filled out manually. When using this option, additional options are displayed in the Appearance dropdown list to automatically include underlines and borders around fields on the PDF without changing the FileMaker layout.

Simply choosing a record set and saving the PDF doesn’t provide any more value than “printing” a layout to PDF using the Mac OSX print-to-PDF feature or using a PDF printer driver in Windows. But the extended options in FileMaker can add a great deal more to your PDF.

The Options button includes PDF specific settings such as meta-data (author, subject, keywords, etc.), security settings to add a password to the PDF, and default PDF view settings. Also, the check boxes on FileMaker’s “Save Records as PDF” dialog box allow you to automatically open the PDF after it’s saved or automatically attach the PDF to an email draft in your default email client. For developers, using FileMaker’s Save as PDF feature is available as a script step and can be integrated into your report scripts to quickly and easily automate report distribution through email.

Saving records as Excel

The other option in the “Save/Send Records As” sub-menu is “Excel…”. Similar to the PDF option, you will be prompted with a dialog box where you can enter the spreadsheet file name and location where you would like the spreadsheet to be saved. Also, you can choose whether to save the “Records being browsed” or the “Current record”. There is an Options button to add meta-data to your spreadsheet including worksheet name, title, subject, and author. The same check boxes are available to open the file after saving or automatically attaching the file to an email message in your default email client.

Unlike saving a PDF, the spreadsheet will not contain FileMaker formatting, so selecting the “Current record” would result in a single row spreadsheet and selecting “Records being browsed” would result in a multiple row spreadsheet regardless of the current FileMaker layout. Additionally, you can choose to save the spreadsheet in the new .xlsx format or the older .xls format.

To make the Save as Excel process even easier, all fields on the current layout will automatically be included as columns in the spreadsheet. Developers can take advantage of this feature in scripts by creating a hidden layout that is active when the spreadsheet is saved. Fields can be added or removed from the spreadsheet by simply adding or removing them from the layout.

If you have any questions about this tip or have ideas, suggestions about other topics to explore, please contact me at jason.mundok@itsolutions-inc.com or 866.PICK.ITS.