Unicode vs non-unicode

In order to support legacy conversions who had no desire and/or requirement for unicode support.

Regards,

Michael

Michael Barry
Aspacia Systems Inc
866.566.9600
312.803.0730 fax
http://www.aspacia.com/

This email, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this email, you are hereby notified that any dissemination, distribution or copying of this email, and any attachments thereto, is strictly prohibited. If you have received this email in error, please immediately notify me by telephone and permanently delete the original and any copy of any email and any printout thereof.




On Apr 1, 2010, at 7:55 AM, Pim Zandbergen wrote:

> Can anyone tell what the use is of having a non-unicode version
> of Epicor 9 for SQL Server?
>
> There must be some advantage, because Epicor keeps maintaining
> and introducing versions that lack Unicode support.
>
> When Vantage 8 for Progress databases was released, it was
> defaulting to Unicode (UTF-8) from the start. There still is only a
> Unicode version of Epicor 9 for Progress. This makes sense.
>
> The first Vantage 8 release for SQL Server lacked Unicode
> support. Later, a second Unicode capable version was
> introduced. The difference was such that Epicor must maintain
> different R-Code for unicode and non-unicode variants.
>
> Therefore, it surprises me they keep maintaining the
> non-unicode version, and even lift it to new architectures,
> like the upcoming native 64-bit variants.
>
> As far as I can tell, it does not matter for SQL Server
> itself whether you store Unicode data or not. SQL Server
> always stores everything as double-width UTF-16, so
> there is no gain or loss in disk usage or bandwidth.
>
> So why all the fuss to keep such a deficiency intact?
>
> Thanks,
> Pim
>
>



[Non-text portions of this message have been removed]
Can anyone tell what the use is of having a non-unicode version
of Epicor 9 for SQL Server?

There must be some advantage, because Epicor keeps maintaining
and introducing versions that lack Unicode support.

When Vantage 8 for Progress databases was released, it was
defaulting to Unicode (UTF-8) from the start. There still is only a
Unicode version of Epicor 9 for Progress. This makes sense.

The first Vantage 8 release for SQL Server lacked Unicode
support. Later, a second Unicode capable version was
introduced. The difference was such that Epicor must maintain
different R-Code for unicode and non-unicode variants.

Therefore, it surprises me they keep maintaining the
non-unicode version, and even lift it to new architectures,
like the upcoming native 64-bit variants.

As far as I can tell, it does not matter for SQL Server
itself whether you store Unicode data or not. SQL Server
always stores everything as double-width UTF-16, so
there is no gain or loss in disk usage or bandwidth.

So why all the fuss to keep such a deficiency intact?

Thanks,
Pim