There may be an error in your database that did not show up in database verification. You are making a huge leap in versions and might benefit from a "staged" conversion where the database is upgraded to a more recent BDE version and then to 2017. Tech support should be able to help or their are a number of consultants, such as myself, that can assist.

Caren: Thanks. Don't you agree that support should not have answered flippantly and quickly (and in substandard English) that everything would be fine? I'm the IT person for the registered user and have been in IT 26 years, which is long enough to know that huge leaps don't always go well. When the product's own support team gives an incorrect answer immediately (rather than even having taken the time to research whether there are known issues with BDE upgrades. I'm all for staged conversions, but that'd require either them converting the data to another version (say 2013?) as we're not buying another version of Timeslips to compensate for something they said wouldn't be a problem.

I'll start with support and see where that takes us. Regardless, I see your number, and we'll call if we require assistance beyond support.

Support should never be flippant.
Hope it works out for you.

I suggest finding a consultant who can upgrade your program to interim versions. I had a similar situation with a client and upgraded to 2010 and then 2015 to make sure the conversion was not because of 2017. Also, the error will tell you what version it stopped at.

I'm having a hard time understanding why you thought a quick answer was "flippant." Was it just because it was quick? I would think that a quick answer from tech support would be a good thing. Should they have taken longer to give you the same answer? Would that have seemed less flippant?

Also, v2017 is really NOT a NEW product. The Firebird SQL product has been in use by our Premium/subscription customers for over a year. All of us in the Timeslips Certified Consultant community have been watching it very closely for issues, and the truth is that there have been very few. Not none, but few.

We are all cautious about it, but so far it seems to be doing pretty well. (I know, it's sort of spooky.)

I agree with previous advice about a stepped conversion. This has been true within the BDE version for some time. When trying to take a database up through several versions, we do occasionally see an issue, and a stepped conversion almost always resolves it. I would also want to make sure I had a good v2016 BDE database before then trying to go from BDE/v2016 to Firebird SQL/v2017, essentially breaking the process down into smaller steps to isolate the issue.

From the errors you have shown here it looks like more of a BDE issue than anything to do with Firebird SQL. I'm pretty sure (but not 100% positive) that the conversion wants to first convert your database from v2006 to v2016 in order to get all the changes and new tables that got introduced in that 10 year span. Then it should try to take it from BDE to Firebird SQL. From your errors, it does not appear that it is even getting from BDE/v2006 to BDE/v2007.

You are welcome to contact official technical support about it (likely you can get them to help you for no additional $$$ as it is a new purchase), or privately contract with any of the Timeslips Certified Consultants. The good news is, there ARE options.

Best of luck on your migration.

Nancy:


First of all, thank you for your analysis.

With respect to your reply: the fact that two support professionals in this forum agree with the method of a stepped conversion indicates that Timeslips support should have known this too. I'd have gone here first, but I was not allowed access to this forum or to support prior to having purchased the product. So, I was relying on sales who told me what you did: that the upgrades had been part of a different release. Regardless, the salesperson advised me that Timeslips 2017 as an independent product had been released on June 27.

If it had only been available to people who had upgraded through every version, then, unless they had tested their conversion utility thoroughly, and with every version in use, they had no way of knowing whether a conversion would have gone smoothly from 2006. That's what they should have said.

Having been in IT 26 years, I've had to deal with a very wide variety of support people. It's clear you've been with Timeslips a while, and you're intimately familiar with the product. You've probably faced some vexing problems that do not have simple answers. You've probably dealt with many support people too, and know that IT and/or software have many variables.

A skilled and knowledgeable professional would have understood the ramifications of the question, and MIGHT have admitted that they did not know for certain that a conversion from 2006 to 2017 would work straight out of the box. I thought to ask about conversion prior to installation because this wasn't my first rodeo. :).

If two consultants here knew that stepped conversion would be best, then presumably a senior support person who works for Timeslips would have known that too. The clearly-junior person in chat with me did not know, and didn't ask his supervisors/superiors.

To have answered as quickly as he did indicated that one or more of a few things; a) he didn't take the question seriously b) didn't understand it beyond the surface level, c) didn't have the humility to even say, as many support professionals do, "Let me research that for you" (code for "I don't know"). Not knowing is fine. Nobody knows everything, and nobody's prepared for every combination of variables. Having a wrong answer right off the top of his head is NOT fine. Also, his English was quite poor. If he actually was in Atlanta as he said he was, he really shouldn't have been doing chat support with people in the US. If he'd known his stuff or had the humility to answer honestly, he'd have come off a lot more credible.

Poor English on top of wrong answers, on top of a $700 product is not a good combination and does not speak well of the company. If the end user still had her 2006 media, we'd not have upgraded.

As for having a consultant convert the data: that wasn't part of the plan, could keep the end user down for days, and/or would require her to do entry a second time because Timeslips own support was wrong. If Timeslips will do a data conversion ("on the house"), and do it quickly, they can be considered as standing by their product.

Thanks for your insight on the matter.

Dana

Dana:

I hear you. I would imagine you were trying to do this over the holiday weekend to minimize disruption to your client, and that's always a bummer when it doesn't go as expected. I could be wrong on that, just let me know. But you've clearly been at it a while and have a high frustration level right now. Been there, done that, got the t-shirt (and scars), and feel your pain. :-)

Let's just say right off the bat, bad grammar and English are NEVER acceptable. Period.

Here's the point I was trying to make (now, not even so much for you individually, but for others who might happen across this thread later): I still think you got good advice from technical support. It just didn't turn out to work IN YOUR CASE, this time.

If someone called me today and said they were going from 2006 to 2017 and asked "Will it convert?," my answer would be pretty much what they told you. Give it a shot, it should work, usually does. (Especially since you are coming from 2006, I've seen it be more likely that a database will have trouble going from 2005 to 2006, but once they make it over that hump, it usually works through the remaining versions.) Your chances are really good that it will. It won't cost you anything extra to try it.

Please understand that they do not rewrite the converter every year. They just add the delta. So your database will first do a 2006 to 2007 conversion, then a 2007 to 2008 conversion, etc. , etc. Again, it doesn't seem like your version is even getting through step 1 - the 2006 to 2007 conversion. Now that part of the conversion has been out there running and working since 2007, so it's not really new, different, or untested.

It is only when a conversion DOESN'T work as planned, that we recommend a stepped conversion. So a stepped conversion is a whole different subset of conversion, and not a default recommendation for all databases. That costs money to have someone get involved. So again I would have said, hey, try it yourself first. It should work. IF it doesn't work, then we can see what your options are.

I don't have a good idea of how often it does/doesn't work because by the time folks get to me they usually already have a problem. So I don't have a good sense of the percentages that do convert just fine.

I do know that when I sell an upgrade, I do things a little differently than Sage themselves might. I pull in a backup of my client's data on a Friday afternoon. Run the conversion over the weekend. That gives me plenty of time to see if it goes smoothly or hiccups, and I have go mess with it. I run and compare some reports, and IF I like it, then on Monday, we roll out the new program. I transfer in the new backup, restore the converted data, and we are off to the races. That way, my client's set up is never changed until I am sure that the new database is ready to roll. Most of the time, it converts no problem.

So, you gave it a shot, it didn't work. Now you have two options, call Sage and see if they will convert it for you for free. Or call a consultant and pay them to help you with it. If I were you, I'd probably give Sage a try first. Again, no extra money (but yes, extra time). A consultant can probably do the conversion faster, with less corporate run around and hassle, but then you are paying for speed and experience. That's a different thing.

Let us know how it turns out. At least we will all learn what a "Could not load STRINGTABLE resource ID: 21999" error is all about. That's a new one on me. Might help the next person.

Hang in there, we are rooting for ya!

Thank you for your emotional support and validation! :)...I will start with finding out about the error and the conversion.

Also, forgot to mention, when I searched this forum about conversion, there was no direct hit, but it did pull up a post /answer by you saying that there shouldn't be a problem converting from 2006 to 2015. :)

I'll keep you posted.
Best,
Dana

Excellent! And I agree that Roger is THE MAN!

Just as a follow up, your post made me curious, so I did a bit of testing yesterday.

Converted three databases on a little laptop that I use for presentations, so not a honking server or anything super powerful. Just a little Windows 8 Home converted to Windows 10 machine, running two processors at 2.20 GHz and 4 GB of Ram. Likely WAY more under powered than anything you would run in a office environment.

Database 1 - converting from Timeslips 10.5 to 2017
Slips = 54,000
Clients = 5,025
Time to convert = 3 hours 17 minutes, no errors

Database 2 - converting from Timeslips 2015 to 2017
Slips = 182,791
Clients = 814
Time to convert = 3 minutes, no errors

Database 3 = converting from Timeslips 2011 to 2017
Slips = 299,130
Clients = 27,585
Time to convert = 2 hours 28 minutes, no errors
*This one was likely slowed down a bit because I was streaming a WNBA game - Atlanta Dream 77 vs. Seattle Storm 64, while running the conversion :-) Let's go Dream!

Also, I can confirm that the conversion DOES in fact step the old data through all of the old BDE conversions before going from v2016 BDE to v2017 Firebird SQL.

Hope your client is up and running soon. Thanks for letting us know the outcome.