Virtual Enrollment Party

I know that not all of you use scripts that import data from another file, so if you don’t, this is going to be useless info. But if you DO, keep reading in the spirit of “It’s less painful to learn from someone ELSE’S mistake.”

When you set up an import script, you match up the fields in the order in which they should match up for the import. The annoying part for me has always been that I couldn’t “re-order” the fields on the left side of the import screen—the ones from the “sending” database. They always seemed to be in some sort of random order, not alpha.

Today I learned that the order is not at all random. It’s specifically in the order in which the fields were originally created.

So, what happens when you DELETE a field (most painfully an early-created one) from that source database? Well, sports fans, all your import scripts that depend on that database have their import order changed. The left side of the import screen changes order, shifting up to remove the space taken by the deleted field. The RIGHT side (receiving database) fields DO NOT change, meaning that they no longer match up where they used to. An “imaginary” example would have the HorseTotal going into the Grade field. Badbadbad.

And even worseworseworse, once that original field was deleted, it doesn’t do any good to go back and put it back in. Since it’s now been the LAST created field, it’s just going to plop itself at the bottom of the import list. So the only solution is to go through every script that includes an import step and manually reorder the import order.

The better solution would have been to RENAME the no-longer-necessary field, rather than deleting it. I did not learn this by reading a book or thinking logically through this, but through bitter experience (probably the best way to remember at my age). If I had it to do over, all my unnecessary fields would have been renamed to ZZoldWhateverTheyWere so that they could be easily identified as no longer necessary, but they’d have stayed within the file. I seriously hope I remember that next time!!

Posted by Becky at 09:28 AM | Permalink | Comments (0) | TrackBacks (0)

I got my first question about the State Fair entry databases this morning, so I know that it’s Fair Time in Iowa!!!

This is just a little reminder (it’s also in the instructions) that no matter whether you intend to enter communications, exhibits, or livestock, you ALWAYS start by double-clicking on the 2008StateFairEntry.exe icon as shown in the picture (View image). In that same folder, there are files named “comm.sf8”, “livestock.sf8”, and “exhibit.sf8” BUT if you attempt to double-click on those, your computer will not know what program should be running. You actually access those files through the opening screen of the 2008StateFairEntry.exe program.

I sent this info to a variety of lists a few minutes ago, so some of you may get two notices. Future info about the state fair will ONLY come out through the blog and the 4h-statefair mailing list, so please be sure that you are subscribed to either the blog notification list or the 4h-statefair mailing list if you need that information. If you received an email this morning with the subject line "You're subscribed to the 4h-statefair mailing list", you are. If not, you're not!!

Posted by Becky at 10:32 AM | Permalink | Comments (0)

This post is a continuation of the Blue Ribbon and Vista posting earlier today.

By now, there are two important pieces of information from Extension IT that you need to be aware of. The first one is the April 15 deadline for any computers that you want loaded with WindowsXP. After that date, all computers WILL be loaded with Vista, no exceptions. The other information that's important is that Extension IT is coordinating a "bulk buy" of Filemaker 9 licenses for county use. (For more information, go to Tech News Feb. 26.)

Filemaker 7 and 8 will not run on Vista. Well, technically version 8 will sort of run, if you don't mind that the screen turns black every time you click on something, but let's assume that's not acceptable. Version 8.5 WILL work, IF you have installed a Vista update. Filemaker 9 is fully Vista compatible. The really good news is that it is also fully compatible with Filemaker 7 & 8. What that means is that if you have a Filemaker 7 database, you can open it using Filemaker 9 on one computer, then later open it using Filemaker 7 on another one. The extension at the end of the filename will still be ".fp7" as it was in both Filemaker 7 and 8.

So, why would you need to purchase Filemaker 9 this time? Only if you think you're going to have a Vista computer that will need to run Filemaker, truthfully. But remember, Vista is not going away. Not just this year's computers, but all computers from now on, will have Vista installed on them. So plan ahead. The opportunity that Mike Mauton is coordinating for you is a good one--purchasing Filemaker individually is more expensive.

Other tidbits--the state fair entry system will continue to be "runtime", which means that you don't have to have ANY Filemaker to open it. The judges database, however, will only be available in ".fp7", so if you never upgraded to version 7 or 8, now is a good time to buy a license for version 9 so that you can use that database. I'm kind of assuming the same things are true about the staff directory and the pesticide directory, but it's just a guess.

Interested in learning more about how to use Filemaker? I'm tentatively planning that I'll offer some beginner and intermediate workshops next fall. I want to have time to work with my own version 9, and see whether there are new features that I should add to the workshop. I'll send out more information about those workshops as soon as I have a definite time frame.

If you have questions about Filemaker and Vista, please feel free to post a comment to the blog! If you have specific questions about Vista only, you're going to be better off talking to somebody at Extension IT!!

Posted by Becky at 12:03 PM | Permalink | Comments (0)

In Filemaker, you can create fields that are called "global", and what they do is store the exact same piece of data in each record in the file. That seems contrary to the purpose of a database, which is to store different information in each record, doesn't it?

But there are some times when each record needs to hold the same information, and a really good example of that (at fair time) is the Fair Weigh Date field. All animals are weighed at the fair on the same day, so that field (used in the calculation for Rate of Gain) would be the same in each record.

To define a global field, you'd go to File>>Define Database and highlight the field. Then, when you click the Options button, you'd next choose the Storage tab at the top of the input box, and check the "Global storage" option as shown below. Then, when you need to change the date next year, you only change it once and it's changed for all records. Even nicer if you FORGET to change the date before you enter all the livestock... you can change it at any point, and all the calculations are re-done immediately!

This is only one example of using a global field, but it illustrates a perfect use. Do you have other ideas about where you could use this?

Posted by Becky at 01:41 PM | Permalink | Comments (1)