Skip to main content

Hi,

I'm with the Far West Racing Association. We have our own ski race results program, and that generates SplitSecond-compatible XML data bases and, as a backup, comma-separated .csv files, that the resorts import into SplitSecond on race day.

This has all worked great everywhere we've raced except for at Sugarbowl, California, where their SplitSecond program won't open our databases nor import our .csv files. We've had this problem there twice this season, and since we're going back their for our finals in a couple of weeks I'd like to get it sorted out.

They have SplitSecond Club 4.03 revision 3. When they tried to read the XML files in it failed with an “invalid file name” error (I doubt its really the file names that its complaining about because we tried copying the files to a local directory and changing their names to something very simple). So we tried to import the .csv files, but for some reason they did not work either – it ended up with “bib,first,last” all in the first column.

We lucked out a bit in that we also generate a single printable text file with all the racers in, and that did import OK. Worst case, I can generate those for each course, but I'd like to get the problem sorted if we can.

I just downloaded the latest SplitSecond Ski-Club version (4.03 rev 6) and tried opening and importing the same files that failed at Sugarbowl (I still have them on my memory stick) and it worked fine. Also the same .csv files imported fine into multiple columns as they should.

Anyone got any idea what may be causing this? Could this be a bug in rev 3 that was fixed in rev 6?
Original Post

Replies sorted oldest to newest

Doesn't sound like a bug that was fixed in the revision list: http://splitsecond.com/club_changes.php but Geoff should answer.

The obvious question of course, is why would anyone not just be using Split Second?

That being said, I wouldn't open an XML file created in a program other than Split Second in Split Second, I would definitely use the import feature. As far as why you are having the problem, did you open the files first on the PC you were importing them? Some settings in Excel will change the csv file, and that could do it. I would have them load the newest version of the software, e-mail them the file that you were able to import, and see if they can do it. Finally, sometime naming issues in Windows can cause problems like this. Most people don't have the file setting set to show the file extension of known file types. Make sure this setting is changed and that might help.
Good luck,
Jenna
To answer Jenna's questions, we don't use SplitSecond as our primary results processing program because we run a handicapping system that it doesn't support. In the Far West Racing Association races we run pacesetters, from their times we calculate a "par" for the course, and we then calculate handicaps for all the racers based on that. Then the racers compete in separate skill levels based on their handicaps (http://www.slracing.org/results/Handicaps.pdf).

And also the points system that we use is dependant on the handicapping, with points getting reduced when racers don't run their handicap. So we need to run a special program to deal with all this.

As for why we generate SplitSecond-compatible database files, we used to simply export .csv files that could be imported into SplitSecond, but we found that the competency level of the operators at the resorts would vary, and occasionally they would not know what to do with those. Simply giving them a pre-prepared race database and saying copy this over has proven less problematic.

I regularly download the latest SplitSecond and make sure it can open our databases.
Follow up: I got an email from Sugarbowl saying that their IT people had looked at the problem and it should be OK now. I don't know what they changed, but we just had our championships weekend there and this time everything went fine with their SplitSecond opening our XML databases.

For the problem I mentioned above that we previously hit importing .csv files, Jenna came up with a likely explanation. SplitSecond remembers the previous comma/tab separated choice on import, and so if it had previously imported a tab-separated file it may have been set for that. And if the operator did not then change it over to comma-separated we would have seen what we did. I can't say definitely that's what happened, but it seems to be a likely explanation.

Add Reply

Post
×
×
×
×
Link copied to your clipboard.
×