When we use upgrade wizard to migrate ms access to sql server, the fields
data type text is converted to nvarchar.
My question is, Can I change nvarchar to varchar? These changes does it not
affect nothing?

Thanks

JCP

nvarchar supports Unicode data. Functionally, it's the same as varchar, but
it may require additional storage - I think Unicode requires two bytes per
character instead of one - but I could be wrong. If your data is always
going to be English (or a similar ASCII based language) you can switch the
data types back to varchar.


"Jose" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> When we use upgrade wizard to migrate ms access to sql server, the fields
> data type text is converted to nvarchar.
> My question is, Can I change nvarchar to varchar? These changes does it
> not affect nothing?
>
> Thanks
>
> JCP
>
>

My data is enghish or portuguese, so, is derived from latin language.

Do you think can i change nvarchar to varchar without impact problems?
Thanks,
Jose
"Scott Lichtenberg" <(E-Mail Removed)> escreveu na mensagem
news:(E-Mail Removed)...
> nvarchar supports Unicode data. Functionally, it's the same as varchar,
> but it may require additional storage - I think Unicode requires two bytes
> per character instead of one - but I could be wrong. If your data is
> always going to be English (or a similar ASCII based language) you can
> switch the data types back to varchar.
>
>
> "Jose" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> When we use upgrade wizard to migrate ms access to sql server, the fields
>> data type text is converted to nvarchar.
>> My question is, Can I change nvarchar to varchar? These changes does it
>> not affect nothing?
>>
>> Thanks
>>
>> JCP
>>
>>
>

Portuguese has diacritical symbols in its alphabet, so you need to use a
code page if you want to go the ASCII road. Everytime you use a code page,
there is always a possibility that you will have problem if your data is to
be access by a machine which doesn't use the exact same code page; so for
example someone who is greek, russian, chinese or even french - whose
alphabet is close but not identical to the portuguese - will have problem
accessing or updating your data.

If I were you, I would stop bothering myself and Unicode. There is alreay
enough problems in life so that you don't really have the need (or the
luxury) to add more to it. You database was already running fine in Access
with Unicode, why would you want to start changing things now?

--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)


"Jose" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
> My data is enghish or portuguese, so, is derived from latin language.
>
> Do you think can i change nvarchar to varchar without impact problems?
> Thanks,
> Jose
> "Scott Lichtenberg" <(E-Mail Removed)> escreveu na mensagem
> news:(E-Mail Removed)...
>> nvarchar supports Unicode data. Functionally, it's the same as varchar,
>> but it may require additional storage - I think Unicode requires two
>> bytes per character instead of one - but I could be wrong. If your data
>> is always going to be English (or a similar ASCII based language) you can
>> switch the data types back to varchar.
>>
>>
>> "Jose" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>>> When we use upgrade wizard to migrate ms access to sql server, the
>>> fields data type text is converted to nvarchar.
>>> My question is, Can I change nvarchar to varchar? These changes does it
>>> not affect nothing?
>>>
>>> Thanks
>>>
>>> JCP
>>>
>>>
>>
>
>

uh, twice the number of records per page is a compelling reason, IMHO

I think that yes, you should use varchar for almost everything,
nvarchar-- where appropriate.

-Aaron



On Oct 17, 9:43*am, "Sylvain Lafontaine" <sylvain aei ca (fill the
blanks, no spam please)> wrote:
> Portuguese has diacritical symbols in its alphabet, so you need to use a
> code page if you want to go the ASCII road. *Everytime you use a code page,
> there is always a possibility that you will have problem if your data is to
> be access by a machine which doesn't use the exact same code page; so for
> example someone who is greek, russian, chinese or even french - whose
> alphabet is close but not identical to the portuguese - will have problem
> accessing or updating your data.
>
> If I were you, I would stop bothering myself and Unicode. *There is alreay
> enough problems in life so that you don't really have the need (or the
> luxury) to add more to it. *You database was already running fine in Access
> with Unicode, why would you want to start changing things now?
>
> --
> Sylvain Lafontaine, ing.
> MVP - Technologies Virtual-PC
> E-mail: sylvain aei ca (fill the blanks, no spam please)
>
> "Jose" <perd...@hotmail.com> wrote in message
>
> news:%(E-Mail Removed)...
>
>
>
> > My data is enghish or portuguese, so, is derived from latin language.
>
> > Do you think can i change nvarchar to varchar without impact problems?
> > Thanks,
> > Jose
> > "Scott Lichtenberg" <do...@reply.com> escreveu na mensagem
> >news:(E-Mail Removed)...
> >> nvarchar supports Unicode data. *Functionally, it's the same as varchar,
> >> but it may require additional storage - I think Unicode requires two
> >> bytes per character instead of one - but I could be wrong. *If your data
> >> is always going to be English (or a similar ASCII based language) you can
> >> switch the data types back to varchar.
>
> >> "Jose" <perd...@hotmail.com> wrote in message
> >>news:(E-Mail Removed)...
> >>> When we use upgrade wizard to migrate ms access to sql server, the
> >>> fields data type text is converted to nvarchar.
> >>> My question is, Can I change nvarchar to varchar? These changes does it
> >>> not affect nothing?
>
> >>> Thanks
>
> >>> JCP- Hide quoted text -
>
> - Show quoted text -

> uh, twice the number of records per page is a compelling reason, IMHO

Weak reason in my opinion. First, it's not 100% of fields who are of type
characters; if you add to that the space occuped by indexes and empty space
here and there, the difference between a database based on Ascii exclusively
and one based on Unicode is usually around 30% more of space disk. Most
operations inside a database are based on numeric key and/or datetime; which
give us an upper limit of 10% slower but this is an upper limit and it will
be around 1~2% for most operations in a real case scenario excerpt for
string searching. For string searching, this will be around 20% but in the
case of string searching, we usually don't care at all about speed.

IMHO, having a Damocles' sword hanging over your head for 1% or 2% more of
performance is totally absurd.

--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)


"a a r o n . k e m p f @ g m a i l . c o m" <(E-Mail Removed)> wrote in
message
news:d92058a6-5b75-465b-a5f7-(E-Mail Removed)...
uh, twice the number of records per page is a compelling reason, IMHO

I think that yes, you should use varchar for almost everything,
nvarchar-- where appropriate.

-Aaron



On Oct 17, 9:43 am, "Sylvain Lafontaine" <sylvain aei ca (fill the
blanks, no spam please)> wrote:
> Portuguese has diacritical symbols in its alphabet, so you need to use a
> code page if you want to go the ASCII road. Everytime you use a code page,
> there is always a possibility that you will have problem if your data is
> to
> be access by a machine which doesn't use the exact same code page; so for
> example someone who is greek, russian, chinese or even french - whose
> alphabet is close but not identical to the portuguese - will have problem
> accessing or updating your data.
>
> If I were you, I would stop bothering myself and Unicode. There is alreay
> enough problems in life so that you don't really have the need (or the
> luxury) to add more to it. You database was already running fine in Access
> with Unicode, why would you want to start changing things now?
>
> --
> Sylvain Lafontaine, ing.
> MVP - Technologies Virtual-PC
> E-mail: sylvain aei ca (fill the blanks, no spam please)
>
> "Jose" <perd...@hotmail.com> wrote in message
>
> news:%(E-Mail Removed)...
>
>
>
> > My data is enghish or portuguese, so, is derived from latin language.
>
> > Do you think can i change nvarchar to varchar without impact problems?
> > Thanks,
> > Jose
> > "Scott Lichtenberg" <do...@reply.com> escreveu na mensagem
> >news:(E-Mail Removed)...
> >> nvarchar supports Unicode data. Functionally, it's the same as varchar,
> >> but it may require additional storage - I think Unicode requires two
> >> bytes per character instead of one - but I could be wrong. If your data
> >> is always going to be English (or a similar ASCII based language) you
> >> can
> >> switch the data types back to varchar.
>
> >> "Jose" <perd...@hotmail.com> wrote in message
> >>news:(E-Mail Removed)...
> >>> When we use upgrade wizard to migrate ms access to sql server, the
> >>> fields data type text is converted to nvarchar.
> >>> My question is, Can I change nvarchar to varchar? These changes does
> >>> it
> >>> not affect nothing?
>
> >>> Thanks
>
> >>> JCP- Hide quoted text -
>
> - Show quoted text -

Thanks a lot Sylvain,

I'm thinking to change only to save space.
It´s true, until kmow, using nvarchar I neever had problems.
By another side, I think if varchar also doesn´t bring problems, probably is
good to change the datatype.

Thanks

I
"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)>
escreveu na mensagem news:(E-Mail Removed)...
> Portuguese has diacritical symbols in its alphabet, so you need to use a
> code page if you want to go the ASCII road. Everytime you use a code
> page, there is always a possibility that you will have problem if your
> data is to be access by a machine which doesn't use the exact same code
> page; so for example someone who is greek, russian, chinese or even
> french - whose alphabet is close but not identical to the portuguese -
> will have problem accessing or updating your data.
>
> If I were you, I would stop bothering myself and Unicode. There is alreay
> enough problems in life so that you don't really have the need (or the
> luxury) to add more to it. You database was already running fine in
> Access with Unicode, why would you want to start changing things now?
>
> --
> Sylvain Lafontaine, ing.
> MVP - Technologies Virtual-PC
> E-mail: sylvain aei ca (fill the blanks, no spam please)
>
>
> "Jose" <(E-Mail Removed)> wrote in message
> news:%(E-Mail Removed)...
>> My data is enghish or portuguese, so, is derived from latin language.
>>
>> Do you think can i change nvarchar to varchar without impact problems?
>> Thanks,
>> Jose
>> "Scott Lichtenberg" <(E-Mail Removed)> escreveu na mensagem
>> news:(E-Mail Removed)...
>>> nvarchar supports Unicode data. Functionally, it's the same as varchar,
>>> but it may require additional storage - I think Unicode requires two
>>> bytes per character instead of one - but I could be wrong. If your data
>>> is always going to be English (or a similar ASCII based language) you
>>> can switch the data types back to varchar.
>>>
>>>
>>> "Jose" <(E-Mail Removed)> wrote in message
>>> news:(E-Mail Removed)...
>>>> When we use upgrade wizard to migrate ms access to sql server, the
>>>> fields data type text is converted to nvarchar.
>>>> My question is, Can I change nvarchar to varchar? These changes does it
>>>> not affect nothing?
>>>>
>>>> Thanks
>>>>
>>>> JCP
>>>>
>>>>
>>>
>>
>>
>
>

This contradicts a lot of books from MS press.
I just don't believe in Nvarchar, for nearly any reason whatsoever.






On Oct 17, 7:35*pm, "Sylvain Lafontaine" <sylvain aei ca (fill the
blanks, no spam please)> wrote:
> > uh, twice the number of records per page is a compelling reason, IMHO
>
> Weak reason in my opinion. *First, it's not 100% of fields who are of type
> characters; if you add to that the space occuped by indexes and empty space
> here and there, the difference between a database based on Ascii exclusively
> and one based on Unicode is usually around 30% more of space disk. *Most
> operations inside a database are based on numeric key and/or datetime; which
> give us an upper limit of 10% slower but this is an upper limit and it will
> be around 1~2% for most operations in a real case scenario excerpt for
> string searching. *For string searching, this will be around 20% but inthe
> case of string searching, we usually don't care at all about speed.
>
> IMHO, having a Damocles' sword hanging over your head for 1% or 2% more of
> performance is totally absurd.
>
> --
> Sylvain Lafontaine, ing.
> MVP - Technologies Virtual-PC
> E-mail: sylvain aei ca (fill the blanks, no spam please)
>
> "a a r o n . k e m p f @ g m a i l . c o m" <aaron.ke...@gmail.com> wrotein
> messagenews:d92058a6-5b75-465b-a5f7-(E-Mail Removed)..com...
> uh, twice the number of records per page is a compelling reason, IMHO
>
> I think that yes, you should use varchar for almost everything,
> nvarchar-- where appropriate.
>
> -Aaron
>
> On Oct 17, 9:43 am, "Sylvain Lafontaine" <sylvain aei ca (fill the
> blanks, no spam please)> wrote:
>
>
>
> > Portuguese has diacritical symbols in its alphabet, so you need to use a
> > code page if you want to go the ASCII road. Everytime you use a code page,
> > there is always a possibility that you will have problem if your data is
> > to
> > be access by a machine which doesn't use the exact same code page; so for
> > example someone who is greek, russian, chinese or even french - whose
> > alphabet is close but not identical to the portuguese - will have problem
> > accessing or updating your data.
>
> > If I were you, I would stop bothering myself and Unicode. There is alreay
> > enough problems in life so that you don't really have the need (or the
> > luxury) to add more to it. You database was already running fine in Access
> > with Unicode, why would you want to start changing things now?
>
> > --
> > Sylvain Lafontaine, ing.
> > MVP - Technologies Virtual-PC
> > E-mail: sylvain aei ca (fill the blanks, no spam please)
>
> > "Jose" <perd...@hotmail.com> wrote in message
>
> >news:%(E-Mail Removed)...
>
> > > My data is enghish or portuguese, so, is derived from latin language.
>
> > > Do you think can i change nvarchar to varchar without impact problems?
> > > Thanks,
> > > Jose
> > > "Scott Lichtenberg" <do...@reply.com> escreveu na mensagem
> > >news:(E-Mail Removed)...
> > >> nvarchar supports Unicode data. Functionally, it's the same as varchar,
> > >> but it may require additional storage - I think Unicode requires two
> > >> bytes per character instead of one - but I could be wrong. If your data
> > >> is always going to be English (or a similar ASCII based language) you
> > >> can
> > >> switch the data types back to varchar.
>
> > >> "Jose" <perd...@hotmail.com> wrote in message
> > >>news:(E-Mail Removed)...
> > >>> When we use upgrade wizard to migrate ms access to sql server, the
> > >>> fields data type text is converted to nvarchar.
> > >>> My question is, Can I change nvarchar to varchar? These changes does
> > >>> it
> > >>> not affect nothing?
>
> > >>> Thanks
>
> > >>> JCP- Hide quoted text -
>
> > - Show quoted text -- Hide quoted text -
>
> - Show quoted text -

If you don't believe in nVarchar, why should I care? You are entitled to
your own opinion and if what you see from the world doesn't extend any
further than the walls around you, it's not of my business (or interest) at
all.

--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)


"a a r o n . k e m p f @ g m a i l . c o m" <(E-Mail Removed)> wrote in
message
news:6e9339d0-de7c-413a-98cb-(E-Mail Removed)...
This contradicts a lot of books from MS press.
I just don't believe in Nvarchar, for nearly any reason whatsoever.



On Oct 17, 7:35 pm, "Sylvain Lafontaine" <sylvain aei ca (fill the
blanks, no spam please)> wrote:
> > uh, twice the number of records per page is a compelling reason, IMHO
>
> Weak reason in my opinion. First, it's not 100% of fields who are of type
> characters; if you add to that the space occuped by indexes and empty
> space
> here and there, the difference between a database based on Ascii
> exclusively
> and one based on Unicode is usually around 30% more of space disk. Most
> operations inside a database are based on numeric key and/or datetime;
> which
> give us an upper limit of 10% slower but this is an upper limit and it
> will
> be around 1~2% for most operations in a real case scenario excerpt for
> string searching. For string searching, this will be around 20% but in the
> case of string searching, we usually don't care at all about speed.
>
> IMHO, having a Damocles' sword hanging over your head for 1% or 2% more of
> performance is totally absurd.
>
> --
> Sylvain Lafontaine, ing.
> MVP - Technologies Virtual-PC
> E-mail: sylvain aei ca (fill the blanks, no spam please)
>
> "a a r o n . k e m p f @ g m a i l . c o m" <aaron.ke...@gmail.com> wrote
> in
> messagenews:d92058a6-5b75-465b-a5f7-(E-Mail Removed)...
> uh, twice the number of records per page is a compelling reason, IMHO
>
> I think that yes, you should use varchar for almost everything,
> nvarchar-- where appropriate.
>
> -Aaron
>
> On Oct 17, 9:43 am, "Sylvain Lafontaine" <sylvain aei ca (fill the
> blanks, no spam please)> wrote:
>
>
>
> > Portuguese has diacritical symbols in its alphabet, so you need to use a
> > code page if you want to go the ASCII road. Everytime you use a code
> > page,
> > there is always a possibility that you will have problem if your data is
> > to
> > be access by a machine which doesn't use the exact same code page; so
> > for
> > example someone who is greek, russian, chinese or even french - whose
> > alphabet is close but not identical to the portuguese - will have
> > problem
> > accessing or updating your data.
>
> > If I were you, I would stop bothering myself and Unicode. There is
> > alreay
> > enough problems in life so that you don't really have the need (or the
> > luxury) to add more to it. You database was already running fine in
> > Access
> > with Unicode, why would you want to start changing things now?
>
> > --
> > Sylvain Lafontaine, ing.
> > MVP - Technologies Virtual-PC
> > E-mail: sylvain aei ca (fill the blanks, no spam please)
>
> > "Jose" <perd...@hotmail.com> wrote in message
>
> >news:%(E-Mail Removed)...
>
> > > My data is enghish or portuguese, so, is derived from latin language.
>
> > > Do you think can i change nvarchar to varchar without impact problems?
> > > Thanks,
> > > Jose
> > > "Scott Lichtenberg" <do...@reply.com> escreveu na mensagem
> > >news:(E-Mail Removed)...
> > >> nvarchar supports Unicode data. Functionally, it's the same as
> > >> varchar,
> > >> but it may require additional storage - I think Unicode requires two
> > >> bytes per character instead of one - but I could be wrong. If your
> > >> data
> > >> is always going to be English (or a similar ASCII based language) you
> > >> can
> > >> switch the data types back to varchar.
>
> > >> "Jose" <perd...@hotmail.com> wrote in message
> > >>news:(E-Mail Removed)...
> > >>> When we use upgrade wizard to migrate ms access to sql server, the
> > >>> fields data type text is converted to nvarchar.
> > >>> My question is, Can I change nvarchar to varchar? These changes does
> > >>> it
> > >>> not affect nothing?
>
> > >>> Thanks
>
> > >>> JCP- Hide quoted text -
>
> > - Show quoted text -- Hide quoted text -
>
> - Show quoted text -

What you're saying is directly contradicted in MS Press books.

I just think that what _YOU_ say is your own opinon.
Varchar is just about half the size of Nvarchar.

Anyone with any serious experience in DW / DM / VLDB would be adamant
about using optimal datatypes.
Wasting space- and allowing corrupted data-- is a bad choice.

Using Varchar is safer, IMHO.



On Nov 11, 8:17*am, "Sylvain Lafontaine" <sylvain aei ca (fill the
blanks, no spam please)> wrote:
> If you don't believe in nVarchar, why should I care? *You are entitled to
> your own opinion and if what you see from the world doesn't extend any
> further than the walls around you, it's not of my business (or interest) at
> all.
>
> --
> Sylvain Lafontaine, ing.
> MVP - Technologies Virtual-PC
> E-mail: sylvain aei ca (fill the blanks, no spam please)
>
> "a a r o n . k e m p f @ g m a i l . c o m" <aaron.ke...@gmail.com> wrotein
> messagenews:6e9339d0-de7c-413a-98cb-(E-Mail Removed)..com...
> This contradicts a lot of books from MS press.
> I just don't believe in Nvarchar, for nearly any reason whatsoever.
>
> On Oct 17, 7:35 pm, "Sylvain Lafontaine" <sylvain aei ca (fill the
> blanks, no spam please)> wrote:
>
>
>
> > > uh, twice the number of records per page is a compelling reason, IMHO
>
> > Weak reason in my opinion. First, it's not 100% of fields who are of type
> > characters; if you add to that the space occuped by indexes and empty
> > space
> > here and there, the difference between a database based on Ascii
> > exclusively
> > and one based on Unicode is usually around 30% more of space disk. Most
> > operations inside a database are based on numeric key and/or datetime;
> > which
> > give us an upper limit of 10% slower but this is an upper limit and it
> > will
> > be around 1~2% for most operations in a real case scenario excerpt for
> > string searching. For string searching, this will be around 20% but in the
> > case of string searching, we usually don't care at all about speed.
>
> > IMHO, having a Damocles' sword hanging over your head for 1% or 2% moreof
> > performance is totally absurd.
>
> > --
> > Sylvain Lafontaine, ing.
> > MVP - Technologies Virtual-PC
> > E-mail: sylvain aei ca (fill the blanks, no spam please)
>
> > "a a r o n . k e m p f @ g m a i l . c o m" <aaron.ke...@gmail.com> wrote
> > in
> > messagenews:d92058a6-5b75-465b-a5f7-(E-Mail Removed)...
> > uh, twice the number of records per page is a compelling reason, IMHO
>
> > I think that yes, you should use varchar for almost everything,
> > nvarchar-- where appropriate.
>
> > -Aaron
>
> > On Oct 17, 9:43 am, "Sylvain Lafontaine" <sylvain aei ca (fill the
> > blanks, no spam please)> wrote:
>
> > > Portuguese has diacritical symbols in its alphabet, so you need to use a
> > > code page if you want to go the ASCII road. Everytime you use a code
> > > page,
> > > there is always a possibility that you will have problem if your datais
> > > to
> > > be access by a machine which doesn't use the exact same code page; so
> > > for
> > > example someone who is greek, russian, chinese or even french - whose
> > > alphabet is close but not identical to the portuguese - will have
> > > problem
> > > accessing or updating your data.
>
> > > If I were you, I would stop bothering myself and Unicode. There is
> > > alreay
> > > enough problems in life so that you don't really have the need (or the
> > > luxury) to add more to it. You database was already running fine in
> > > Access
> > > with Unicode, why would you want to start changing things now?
>
> > > --
> > > Sylvain Lafontaine, ing.
> > > MVP - Technologies Virtual-PC
> > > E-mail: sylvain aei ca (fill the blanks, no spam please)
>
> > > "Jose" <perd...@hotmail.com> wrote in message
>
> > >news:%(E-Mail Removed)...
>
> > > > My data is enghish or portuguese, so, is derived from latin language.
>
> > > > Do you think can i change nvarchar to varchar without impact problems?
> > > > Thanks,
> > > > Jose
> > > > "Scott Lichtenberg" <do...@reply.com> escreveu na mensagem
> > > >news:(E-Mail Removed)...
> > > >> nvarchar supports Unicode data. Functionally, it's the same as
> > > >> varchar,
> > > >> but it may require additional storage - I think Unicode requires two
> > > >> bytes per character instead of one - but I could be wrong. If your
> > > >> data
> > > >> is always going to be English (or a similar ASCII based language) you
> > > >> can
> > > >> switch the data types back to varchar.
>
> > > >> "Jose" <perd...@hotmail.com> wrote in message
> > > >>news:(E-Mail Removed)...
> > > >>> When we use upgrade wizard to migrate ms access to sql server, the
> > > >>> fields data type text is converted to nvarchar.
> > > >>> My question is, Can I change nvarchar to varchar? These changes does
> > > >>> it
> > > >>> not affect nothing?
>
> > > >>> Thanks
>
> > > >>> JCP- Hide quoted text -
>
> > > - Show quoted text -- Hide quoted text -
>
> > - Show quoted text -- Hide quoted text -
>
> - Show quoted text -