I cannot get the second one to come over no matter what I try.  It is much more complicated than the first one.  This is the message that I keep getting.  If anyone knows what I am doing wrong, I would greatly appreciate it!

Once you've exported the component files open them in a text editor of your choice and make sure to save with UTF-8 encoding. Then create the zip file from these, I've seen this in the past when moving between sql servers with different collations.

Once you've exported the component files open them in a text editor of your choice and make sure to save with UTF-8 encoding. Then create the zip file from these, I've seen this in the past when moving between sql servers with different collations.

Thanks Jeff!  I ended up creating the workflow from scratch.  Not preferred. However, it seemed necessary with all the error I was getting.

I checked both of the server's collations because I was getting other errors referring to "Latin".  Both servers have the same server collation.  However, I am wondering if this is not what is supposed to be used for CRM.  They are both... SQL_Latin1_General_CP1_CI_AS

We typically do not have to worry about the collation on new installs of Sage CRM as CRM does not inherit the default database Server collation, it creates its own collation on the Sage CRM database during the installation process. These collations are:

• For EN Installations = Latin1_General_CI_AS
• For DE Installations = Latin1_General_CI_AS
• For ES Installations = Modern_Spanish_CI_AS
• For FR Installations = French_CI_AS
• For CS Installations = Chinese_PRC_CI_AS

I do think I have a collation issue.  I am just not sure how bad.

Old database = SQL_Latin1_General_CP1_CI_AS

New database = Latin1_General_CI_AS

We brought components over from the old database (those that were done recently.)

I know I have an issue because I received errors regarding some table level scripts.  Therefore, I decided to disable them until I could troubleshoot them and when I tried to save them I got "Latin" errors.  A TLS that was named Quote Totals in the old system had to be renamed to Quote_Totals in the new system.

What other issues will I run into because I brought components created with SQL_Latin1_General_CP1_CI_AS into a database with Latin1_General_CI_AS.

Unfortunately, bringing the components over has seemed to cause about three times the work that would have been necessary if I had just redone the work on the new server.  Lessons learned.

At this point, I just hope I have something that I can work with without having to scrap and redo everything again.

Following up on this as I am not sure it is clear that there is a question in this reply.  

We brought components from a database  to a new database on a new server with the following collation....

Old database = SQL_Latin1_General_CP1_CI_AS

New database = Latin1_General_CI_AS

As indicated about, I know that this has caused an issue because I was getting errors regarding the table level scripts that were brought over.  Therefore, I disabled them (all of them).  When I did and tried to save, I got an error message.  A field name can only contain Latin letters, numbers and the underscore. The TLS was named Quote Totals and I changed it to Quote_Totals.  As I type this, I am realizing that is really weird because I think that is a system generated TLS and not one of mine.  Therefore, really weird that I got that message.

Anyway, does anyone know what issues I might run into by having brought over components from a different collation? And were I might look to find these errors before a user "hits" them?

Any assistance is greatly appreciated!  Thank you!

There are two system TLS scripts in a default system both called 'Quote Totals'.  One under Quotes and the other under Orders.

But I was wondering...have you looked at creating a test environment in which you change the database collation from SQL_Latin1_General_CP1_CI_AS to Latin1_General_CI_AS

support.microsoft.com/.../how-to-transfer-a-database-from-one-collation-to-another-collation-in

I did consider that after we had already moved to a new install and I discovered the issues with collation.  At this point, I am not sure it would help as we have already moved away from the database that has the wrong collation. 

Lessons learned!!