BLOB Size field does not exist

Hi all! I just encountered a strange problem: I installed Navision 3.70.B DK (19868) on a new notebook running on WinXP. When I try to connect to the db I get this error: “The BLOB Size field on the Object table does not exist in the SQL Server table or view.” On the old notebook - Win2000 - everything is fine … Even if I copy the NAV client from Win2000 to WinXP: Same error. What’s going on here? Any ideas?

Using MSDE on the notebook ?

No, I don’t use a MSDE here. I try to connect to a db (3.70) on SQL Server 2000 Standard EE (on a dedicated server) … I just ran a Windows update on the new XP notebook, to assure that all the .NET Framework, MDAC and stuff are “up-to-date” - still, I get the same error …

So you already have a 3.70 (whatever country) database on that server and your problem is that you cannot access it from the XP notebook, but you can access the same database from another machine ?

Exactly! The funny thing is: when I just copy the NAV client directory from the 2000 pc to another 2000 pc - without installing NAV - I can connect to the db there. When copying from 2000 to XP: no go …

Another remark: On the same server we also run a Dutch 3.70.B database. Usually we access this NL db via 3.70.B NL (19868) client - same build as the Danish. This db I can access from the XP machin using the DK client … (Sorry, if this is getting somewhat confusing)

Well. Must work if You run the client in win2000-compatibility mode then… Regards Alexander

If you can access the DK DB with the NL client as well, then it is definitely a problem with the database itself

Just to be sure - what are the column names in the Object table? You can see this from Query Analyzer or Enterprise Manager. Now what are the names listed in the following table and field, in that same database: Table: [$ndo$dbproperty] Field: [Identifiers] (It will also include entries for the Session and Database File views, but just look at the Object table.) First off, these identifiers should match.

Okay, here we go … @Alexander: Changing the compatibility mode didn’t help … @Thomas: With the DK client I can not access this db either … @Robert: What is condered to be the Object table is table Objekt (with a k); here all field names are in Danish. Looking into the $ndo&property table I see, that 2000000001 is related to Objekt (should be ok) and that the field names are in Danish … BUT: The field for “Blob Size” is written with a different character! Field in Objekt table: BLOB-størrelse Identifiers 2000000001=“Objekt”,1=“Type”,2=“Regnskab”,3=“Id”,4=“Navn”,5=“Rettet”,6=“Kompileret”,7=“BLOB-reference”,8=“BLOB-st›rrelse”,9=“DBM tabel-id”,10=“Dato”,11=“Tid”,12=“Versionsliste”; Could this be the problem? How comes? And: can I simply overwrite this?

sounds like the Control Panel->Regional & language Options are not identical in both machines. have you added the additional Text services & input Languages in the new XP machine?

Well, yes, both notebooks have different regional settings: Win2000 is German, WinXP is English Well, I added the support for Danish language on the XP thing but the error is still the same … even though I start up the notebok with Danish …

The character looks strange because it is stored using an OEM code page and you are viewing it as though it was an ANSI code page character in the tool you’re using. So that’s actually ok. The problem is, on the client machine that does not work, the OEM code page is not matching the code page the character was written in. This is governed by the Advanced settings in Regional Options - the “Language for Non-Unicode Programs”. What is that language setting for the machine where it works - and what is that setting for the machine that does not?

Puuuhhh … thank you VERY much, Robert! [8D] THAT was the trick: The non-unicode language was also set to English, I changed it to German and - voila! - welcome to my Danish database! That’s what I call “international business” [:0)] Again, thank you very much!

Aehm, just a short question: Isn’t the table supposed to have english field names as long as soon as it is ML enabled? Or am I on the wrong plane ?

Yeah, that’s what I also expected! When I create a new db with this client on the same server, the table is named “Object” (now with c) and the field names are in English … I guess, that this db was once created with an older version of NAV and then updated later …


Aehm, just a short question: Isn’t the table supposed to have english field names as long as soon as it is ML enabled? Or am I on the wrong plane ?
Originally posted by - 2006 Mar 21 : 04:49:39

For some unknown navisional reasons, before version 4, the 2,xxx,xxx,xxx objects had localized field names! [}:)] Anna

But it highlights a problem which I’ll look more into, based on your scenario which is pretty simple when it comes down to it. I assume you are using a Windows collation in the database - probably a 1252 code page. Since this matches the 1252 ANSI code page active in windows, Navision lets you in to the database. If they did not match you would get an error about ANSI/OEM code pages not matching which is more informative than what you got, which says nothing helpful. However, the OEM data in the property table, written as OEM 850 I expect, caused this screw up when using the English setting of 437 - and you get the strange error when opening the Object table. I’m afraid the Identifiers field of [$ndo$dbproperty] is a bit of a ghost in the machine and was made because of localization being done in some countries, on system tables in the.stx file, as Anna says.

I had the same problem last week and managed to resolve it with the help of article ID 906164 titled: “You receive a “The BLOB size field on the Object table does not exist in the SQL Server table or view” error message when you use Microsoft Navision to connect to a SQL Server database” Unfortunately the article is subject to a confidentiality agreement and therefore I cannot post it, but NSC’s should have access to it anyway. Hope this helps… Meint

Just read the article - interessting! I think we will go for this option instead of changing the “Non Unicode” setting on each client!