Note: this blog post was originally posted on lambtracker.com and has been moved here for preservation. Some information may be outdated.
We’ve been very busy with LambTracker® development and use. After the ewes were inseminated, we waited a bit, then started doing ultrasounds. We have a relatively inexpensive ultrasound machine, but we’re not skilled in determining pregnancy yet. I made modifications to the EvaluateSheep module to accommodate collecting pregnancy status and number of lambs. To get things running quickly, I did not incorporate those changes into the initial EvaluateSheep module.
Once the ultrasounds were done, we started focusing on some clean-up. We standardized a set of buttons and their locations on-screen so the user experience will now be consistent from activity to activity. I modified the standard look-up-a-sheep code to handle sheep with any ID type. This was then incorporated into all existing modules. Unfortunately, that did cause several bugs to surface that took a while to squash. We finally got it all working again, and we’ll be testing the new ConvertToEID module with our last batch of sheep soon.
Database development is ongoing. I’ve added tables and records to track breeding information. This includes dates and times of rams in and out so that sires can easily be determined. Lambing history has also been added, along with other critical information. I’ve started designing the drug and treatment data tables, but they’re still in progress.
Our next task is to get historical lambing data from our flock formatted and put into the system. We purchased a tool to help us do that. It’s a simple program that can take a CSV file and create either insert or update SQL statements to modify or add to various database tables. It’s a lot faster than entering data by hand, but it does require the user to understand the structure of the database. It works for me, but probably wouldn’t be efficient for an uneducated user. Since my existing records are already in a spreadsheet, I just need to copy over the columns I want to add or modify. Then, I verify that there are no illegal characters in the text fields and run the program. I can then copy the resulting SQL statements and execute them.
Programming for the Lambing module is well underway. I currently have the screens for looking up an ewe to view her lambing record and those for collecting data on new lambs. Next will be writing the code that will accept user input and update the database tables with new lamb info. I also want to go back and merge the two EvaluateSheep modules into one. The final module will handle all three evaluation types: scored traits, real data traits, and user-defined traits. Scored traits get a star rating of 1-5, real data traits measure in units (like weight or circumference), and user-defined traits include written descriptions (like Pregnant, Not Pregnant, etc).
Ken is also working on integrating the existing Print Label program and code into LambTracker® as a separate activity. He is working to provide options on how many labels you wish to print for each tag scanned, plus additional information that can be printed on said labels. We may do some testing of this during shearing to identify specific sheep fleeces, but the primary use will be blood collection for scrapie susceptibility genetic testing. That won’t happen until April, after the sheep are shorn.
We are tracking the time that LambTracker® saves us during standard sheep tasks. We’re also tracking how much time we’re spending doing the double-entry for this year. We can see that significant time will be saved once things are working. Of course, that does not include the time spent creating and debugging the program.
All in all, though, we are making good progress with our system.