Upgraded from 10.8 to 11 to 12 but

Hans Manhave · March 18, 2015, 03:46:38 PM

Upgraded to TAM 12 recently. I know the custom dec system changed. I took the webinar for that many moons ago. However, I am starting to find quite a few problems with the conversion. Significant problems.

Anyone ever notice anything with custom dec content after the "upgrade"?

Mark · March 18, 2015, 03:49:11 PM

Don't think we had any issues with the content, but we are only on 11.1. I am scheduling the move to 2014 R2 shortly.

Lynne Desrochers · March 18, 2015, 04:08:05 PM

No issues with the content and we are on 12. We have our entire benefits department on custom decs. What are you seeing Hans? Perhaps we just didn't notice.

Hans Manhave · March 18, 2015, 04:11:33 PM

Only reason I found something is because some items are extracted totally unrepresentative of the field. Somewhere "they" (being Applied) saw fit to re-arrange the contents of DATA1, DATA2, DATA3 etc.

We have fields with six numbers after the decimal that have lost the decimal. That is disastrous.

I am not particularly appreciating Applied's secrecy of data documentation or lack there of. This dec page system change happens between version 11 and version 12. Whenever I have asked for more info, I never received it after the original info available with version 7.1.1.

For those looking at this forum to see if they want to buy something from Applied or something from their major competitor, those may want to take this in consideration.

Needless to say, I am quite p????d at this point.

Jeff Zylstra · March 18, 2015, 05:28:34 PM

I don't blame you, Hans. I know that you folks rely on custom decs quite a bit, and use TAM in ways that most agencies don't simply because of the non-standard types of coverages you write and that you're also kind of a broker or MGA. That said, you have no less right to depend on the integrity of the data that you entered in TAM and that belongs to you. I would say that someone knew about this but didn't think it was important or wouldn't affect anyone. If not, someone needs to know about this because otherwise you had some data corruption that may show up elsewhere as well.

I would definitely call the manager of support and have a long talk with him or her about this. If you repair your data to include the decimal, will it get taken out again in a future release? I'd say that's important.

Billy Welsh · March 19, 2015, 10:31:06 AM

A Custom Dec is custom by definition. The data put into these should NEVER EVER EVER be affected by any "upgrade." PERIOD.

Why else would you use them??? And what good are they if they can be corrupted without warning?

I realize sometimes they are used due to the lack of an actual Acord, but that does not change my opinion. You all pay A$ handsomely for software that is supposed to maintain data integrity. A court will have no sympathy if you "let" A$ trash your data.

Hans Manhave · March 21, 2015, 07:14:45 PM

If one has a lot of certain custom dec type pages (those stored in APCUSTM2.DBF) then one should not update to version 2013 during lunch time.

My update (on a Saturday) is taking more than an hour and not half way the config for above mentioned file yet.

Update: 2012 to 2013MU1 took 2 hrs and 25 minutes.
Update2: 2013MU1 to 2014MU1 took 2 hrs and 10 minutes.

2014MU1 to 2014R2 took unknown amount of time because my client id / license / serial number is unknown to Applied at this time of the day (Saturday, March 21, 2015 @ 22:30 ) What gives? I can read my support login screen. There is a code there, I have known it for decades. I know the serial or license number just as well. This data hasn't changed, now we have to be secretive about it? I wonder if my firewall settings block the retrieval. It is always something.

Finally, for those using SETPOINT.EXE from Logitech or Dymo Label software 8.5.1 (that's the one currently installed in my office), TAM 2014MU1 hung while installing (tamstart /rr) at workstations that had these active. Using task manager to end them was key to finishing the install on the workstations. It got stuck on some OCR.TTF file. I'm not sure if it was one software or the other or both. I just killed them both for the install and rebooted the stations afterward.

Lynne Desrochers · March 22, 2015, 09:54:57 AM

Hans,
I read somewhere that the code is available when you log into the portal, it's up at the top in the upper right hand corner in grey. Don't know if that's helpful or not.
Lynne

Hans Manhave · March 22, 2015, 04:52:00 PM

There appears to be a port scan coming from 216.206.30.xxx after I attempt the installation.

Not sure where this goes or if it is related.

Jeff Zylstra · March 23, 2015, 09:56:18 AM

In one of your posts,you mentioned that Dymo is not compatible with the new version of TAM. I don't think that is correct. I think that there is some integration piece for DYMO that gets broken when you installed TAM. Just reinstall the DYMO software on the affected machine and it should be fine. DYMO likes to be the last thing installed, and upgrading Outlook, Word or anything else that has a DYMO add-in will break that. A royal pain, but it is compatible.

Hans Manhave · March 23, 2015, 11:11:25 AM

I received word from AS support what our license number is. Will try again the coming weekend.

For some reason our license number is not the complete serial number listed at the TAM/About screen. It is similar but different.

Those upgrading from 2014x to 2014R2 may want to call support to verify their license number before wasting a weekend that was prepared for the upgrade.

Jeff, I will watch that Dymo stuff. Disabling and enabling the add-in appears to have worked today. I guess not everything is TAM's fault. Just so accustomed to that.