Go Back   NexusDB Newsgroups > Support Newsgroups > nexusdb.public.support
Log in
FAQ Members List Calendar Search Today's Posts Mark Forums Read

 
Thread Tools Display Modes
  #1  
Old 14th October 2011, 09:07 PM
Bernhard Roos
 
Posts: n/a
Default Current NLS Version differs from NLS Version of Stored Keys. Tablemust packed

Hello,
we have the following problem. If we zipped a database from our customer
and installed it on our own machine, we get this exception.

1. What can be the reason for this exceptio?
2. I know we can repack the tables and all worked fine. But is there
something what we can do on the destination machine, so that the problem
does not happens?

Best wishes
Bernhard
  #2  
Old 14th October 2011, 09:34 PM
Keith Johnson[NDX]
 
Posts: n/a
Default Re: Current NLS Version differs from NLS Version of Stored Keys.Table must packed

On 14/10/2011 10:07, Bernhard Roos wrote:
> Hello,
> we have the following problem. If we zipped a database from our customer
> and installed it on our own machine, we get this exception.
>
> 1. What can be the reason for this exceptio?
> 2. I know we can repack the tables and all worked fine. But is there
> something what we can do on the destination machine, so that the problem
> does not happens?
>
> Best wishes
> Bernhard



I believe the exception is normal and nothing to worry about. It's
basically to do with Locales on machines be different, even if the
locales are the same, Microsoft decided to make the locales act
differently on different versions of Microsoft too. So the only sure
way to make sure Indexes are correct is to re-index the files.
  #3  
Old 14th October 2011, 10:51 PM
Thorsten Engler [NDA]
 
Posts: n/a
Default Re: Current NLS Version differs from NLS Version of Stored Keys. Table must packed

Keith Johnson[NDX] wrote:

> On 14/10/2011 10:07, Bernhard Roos wrote:
> > Hello,
> > we have the following problem. If we zipped a database from our customer
> > and installed it on our own machine, we get this exception.
> >
> > 1. What can be the reason for this exceptio?
> > 2. I know we can repack the tables and all worked fine. But is there
> > something what we can do on the destination machine, so that the problem
> > does not happens?
> >
> > Best wishes
> > Bernhard

>
>
> I believe the exception is normal and nothing to worry about. It's basically
> to do with Locales on machines be different, even if the locales are the
> same, Microsoft decided to make the locales act differently on different
> versions of Microsoft too. So the only sure way to make sure Indexes are
> correct is to re-index the files.


Keith is correct.
  #4  
Old 14th October 2011, 11:07 PM
Eivind Bakkestuen [NDD]
 
Posts: n/a
Default Re: Current NLS Version differs from NLS Version of Stored Keys. Table must packed

> 1. What can be the reason for this exceptio?

The link to check when new versions are released:

http://www.nexusdb.com/support/index...exusdbbreaking

--
Eivind Bakkestuen [NDD]
  #5  
Old 15th October 2011, 03:00 AM
David Miller
 
Posts: n/a
Default Re: Current NLS Version differs from NLS Version of Stored Keys. Table must packed

This will be a serious issue for support here. Many of my clients buy
new computers and move the software over. Also, this sounds like it
will affect new installs unless I automatically pack my tables on the
new machine when the new install is finished.

It seems to me that the server should check the files on startup (as
you already do), but then instead of making them read only, it should
pack them automatically. Making them read only only breaks everything
and makes our product look like it doesn't work. This is going to lose
sales for us because we provide free demos and free trial software.
People that install the software themselves are not going to be
impressed that the demo or trial is broken immediately upon
installation. There are other databases that repack or reindex files
automatically if even just the index files appear corrupted. That is
the right approach.

I read the following at the link you gave us:

"An exception with relevant info is raised by the server
and can be trapped by the client to detect this condition."

If you disagree for philosophical reasons about the server handling the
packing of tables upon detection of a problem, at least give us some
sample code to take the approach of having the client initiate the
packing. I realize this seems very simple to you guys, and you figure
we are developers who can do this on our own, but we are focused on
many other things and do not know the syntax involved to do what you
say here. What would take you 15 minutes might take me several hours
to figure out because I am not familiar with the exact syntax and
proper events, etc. This can be frustrating when I am trying to answer
telephone calls and inquiries by employees about issues they can't
figure out. Some simple sample code would help tremendously!


Eivind Bakkestuen [NDD] wrote:
> > 1. What can be the reason for this exceptio?

>
> The link to check when new versions are released:
>
> http://www.nexusdb.com/support/index...exusdbbreaking


  #6  
Old 15th October 2011, 05:07 AM
Alessandro Romano
 
Posts: n/a
Default Re: Current NLS Version differs from NLS Version of Stored Keys. Table must packed

Hi Nexus Team,

i have serious problem with NLS version...

I have a application that works entirely on an external device (Flash Drive
or external HD)...

when my clients move the device on a computer with different operating
system ... I need to pack the tables !!!

it's not right ... if the tables are big this can take several minutes ...
(especially on slower external device) !

I hope that you will find another solution for this ....

thanks

Alessandro Romano


  #7  
Old 15th October 2011, 06:37 AM
Roberto Nicchi
 
Posts: n/a
Default Re: Current NLS Version differs from NLS Version of Stored Keys. Table must packed

"Alessandro Romano" <staff@arlsoft.it> wrote:
> Hi Nexus Team,
>
> i have serious problem with NLS version...
>
> I have a application that works entirely on an external device (Flash Drive
> or external HD)...
>
> when my clients move the device on a computer with different operating
> system ... I need to pack the tables !!!
>
> it's not right ... if the tables are big this can take several minutes ...
> (especially on slower external device) !
>
> I hope that you will find another solution for this ....
>
> thanks
>
> Alessandro Romano


I think i will have the same problem when/if ill move to latest nexudb
release.

Roberto
  #8  
Old 15th October 2011, 12:24 PM
Eivind Bakkestuen [NDD]
 
Posts: n/a
Default Re: Current NLS Version differs from NLS Version of Stored Keys. Table must packed

> I hope that you will find another solution for this ....

There is no other solution in the short term, I'm afraid. At least not
as long as you want indexes to keep the correct localized sort order,
ranges and filters to work correctly, etc.


....there is of course one workaround; stay on v3.08 if that works well
enough for you.

--
Eivind Bakkestuen [NDD]
  #9  
Old 15th October 2011, 01:22 PM
Thorsten Engler [NDA]
 
Posts: n/a
Default Re: Current NLS Version differs from NLS Version of Stored Keys. Table must packed

Roberto Nicchi wrote:

> > I hope that you will find another solution for this ....
> >

> I think i will have the same problem when/if ill move to latest nexudb
> release.


Ok, let me explain this again.

For sorting string data, NexusDB calls the Windows API function CompareString
with a specific locale and 2 strings, Windows returns a smaller, greater or
equal result.

The data that windows internally uses for determining this sort order has been
changed by Microsoft between different versions of windows. That means that if
you take the same list of strings, and have them sorted by different versions
of windows, you can end up with the strings in different order.

If you have a list of strings that are supposed to be ordered (like the keys
inside each index page) and you perform a binary search on them, if the actual
order is different then what the compare function returns when performing the
search you can end up in the wrong place.

As a result you can get:
- setrange returning the wrong range
- findkey not finding a key which is actually present
- insert succeeding on a unique index even though the key is already present
- modify and delete failing with a key violation because it can't find the old
key to remove
and so on.

All this is the case in 3.08 and older. You will simply end up silently
corrupting the data in the tables on inserts and getting wrong results from
findkey and setrange, and getting unexplained key violations on modify and
update, all in a seemingly random and predictable pattern.

The changes in 3.09 and later detect such a situation early before there is a
chance to cause any corruption and force you to take the required step to
ensure that the indices in question can be safely and correctly maintained and
searched.

These changes haven't been put in to annoy anyone. They are there because they
are required to ensure the integrity of that tables and the correctness of
search results.

3.10 will add a function to more easily tell you which tables need to be packed.

The reason why tables can't simply be silently packed on open if a NLS
difference is detected is the following: suppose you have an x GB table, do you
really want the nxTable.Open call to take 20 minutes? or time out with an error
after 10 seconds?

If you need to be able to move a table between different versions of windows
without any chance of hitting the NLS version error, you have to make sure that
you are not using locales for the indexed string fields in that table.



  #10  
Old 15th October 2011, 03:55 PM
Brian Evans [NDX]
 
Posts: n/a
Default Re: Current NLS Version differs from NLS Version of Stored Keys.Table must packed

On 14/10/2011 8:24 PM, Eivind Bakkestuen [NDD] wrote:
>> I hope that you will find another solution for this ....

>
> There is no other solution in the short term, I'm afraid. At least not
> as long as you want indexes to keep the correct localized sort order,
> ranges and filters to work correctly, etc.
>
>
> ...there is of course one workaround; stay on v3.08 if that works well
> enough for you.
>


One option is to switch to using only Unicode strings along with
ICU (International Components for Unicode) and CLDR (Unicode
Common Locale Data Repository) so no comparison functions are
used from the OS.

http://site.icu-project.org/
http://cldr.unicode.org/

--
Brian Evans [NDX]
Ottawa, ON, CANADA
GMT-5


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Current NLS Version differs Wolfgang nexusdb.public.support 2 29th July 2011 04:05 PM
Full version of current NexusDB V2 ADO Provider Petr Manas nexusdb.public.support.adoprovider 2 9th July 2007 05:18 PM
Current version Robert nexusdb.public.support 3 15th August 2006 11:27 AM
Current Version: Release 2.00 - June 26th 2005 Hans Hasenack nexusdb.public.support 38 15th March 2006 06:59 AM
Re Current version Richard Wilson nexusdb.public.discussions 2 10th December 2003 04:00 PM


All times are GMT +11. The time now is 07:37 AM.


Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.