the type 4994 was not defined for the function

Belias · 2007-05-07

I encountered this error exporting a table in text format using navision 4.0
(as I wrote in the object)
the table is 12181 (italian object) and there are only 2 personalized lines(developed by another company). even if I delete this modify the error appears.
Why this error appears?

thanks for the help

kriki · 2007-05-08

I tried the same with the standard object but it didn't create an error.
Did you try to recompile it?

Belias · 2007-05-08

yes...i exported the standard object without problems like you, but THIS object (compiled and recompiled many many times) doesn' t want to be exported in text format. I can't see differences between THIS object and the standard (as I deleted all the possible modifies) and i don't know where to ](*,)

Belias · 2007-05-09

ehmm...someone help please?

MTC · 2007-05-09

I have never seen this error message before, so therefor do not have a clue what may be causing it. Someone else may have.....

However, if it is not causing a problem for Kriki, I can only suggest that somehow the object in the database table "Object" has become corrupted in its binary form or there is something in the code that is sending the client haywire.

Obviously, I do not have access to this object so cannot check it myself, but have you tried to note what the changes are and where they happen. Then, open a Cronus database and export its version of the object as a FOB file. Import this into your DB to replace what is already there. Then add whatever changes you noted down and try to recompile it, then export it as text.

PS. Which service pack of v4 are you using? Have you tried it with SP3, it could be a bug in the client.

Belias · 2007-05-09

I'm using version 4.0 no sp...
i have already tried to do everything you say (except use 4.3 version)but without results...the only thing i can think(as you say)is data corruption...
aah...the disadvantages in stealing a customers... #-o

kriki · 2007-05-10

MTC wrote:

However, if it is not causing a problem for Kriki,

:shock: why would it be a problem for me :shock:

I would try with 4.00SP3.
Or if that doesn't work, create a copy of the DB. In that copy, put the original object and put the changes manually.

Belias · 2007-05-10

yes...i put modifies by hand (wonderful englsh!!)...it's the only way...as I thought...this was only "an honor problem"...well, it will remain a mistery...thank you all

petevans · 2007-08-22

Same thing happened to me.

I try to export some objects in txt format (all compiled) and get this error message - using 4.0, no SP.

raven44 · 2007-10-17

hi,
I know this issue is set as [SOLVED] but I found the cause of this error and a simpler fix to rather than just re-do'ing the whole object.

For some reason the Key seems to have become corrupt.
If you delete and re-add the key, it seems to be able to export successfully afterwards.

vaprog · 2007-11-09

I found that this error is triggered when a table has been edited in an C/SIDE Client 5.0 and imported as a binary object into a version 4 database.
It does not occure if you disable the clustered property on all keys of the table in the 5.0 client.

Does this tell somebody how to fix the problem without deleting and recreating the key?

Belias · 2007-11-09

i'm trying to toggle [solved] as this topic still live...by the way..the object isn't involved with 5.0 at all...i'll check the properties when I can, now i'm a bit occupied...

Timo_Lässer · 2007-12-14

raven44 wrote:

For some reason the Key seems to have become corrupt.
If you delete and re-add the key, it seems to be able to export successfully afterwards.

I also got this error and tried everything (except your tip).
After I created a second key and deleted the primary key, I could export my table in text format.
After that, I created the origin primary key as secondary key and deleted the primary key.
I still can export the table in text format.

Many thanks to raven44!

Belias · 2007-12-17

really thanks!I can finally "make [solved] be in my title"!

gnosis · 2008-02-01

Timo Lässer wrote:

raven44 wrote:

For some reason the Key seems to have become corrupt.
If you delete and re-add the key, it seems to be able to export successfully afterwards.

I also got this error and tried everything (except your tip).
After I created a second key and deleted the primary key, I could export my table in text format.
After that, I created the origin primary key as secondary key and deleted the primary key.
I still can export the table in text format.

Many thanks to raven44!

Thanks!
I encountered this in a 4.0 client (no SP) and using 3.6 objects.

Never seen this before, or had problems exporting from this database in the past - it's our DEV server 8-[

Big_D · 2009-02-13

Well Done this worked for me too - deleted the Primary key and put it back in again - didn't even have to save the object after deleting the PK first!

With thanks

David

fverkel · 2010-07-21

I've also encountered this strange error. In NAV 3.70, table Sales Line.
The trick with the primay key works.
Cause ... ? I suspect that it happened a few months ago when importing the object as a .txt.

DigiTecKid · 2010-09-01

Worked in my 3.70A database with a 50000 range table. It was giving me the "type '4994'" message and stopping me from exporting it as text. Deleted the primary key, closed the key window, reopened the key window, put back the primary key. Viola! It came to it's senses... Thanx for the post!!

Belias · 2010-09-02

DigiTecKid wrote:

Worked in my 3.70A database with a 50000 range table. It was giving me the "type '4994'" message and stopping me from exporting it as text. Deleted the primary key, closed the key window, reopened the key window, put back the primary key. Viola! It came to it's senses... Thanx for the post!!

it's really rewarding to see that my topic (and for sure raven's solution) is so helpful! \:D/

vaprog · 2010-09-06

fverkel wrote:

I've also encountered this strange error. In NAV 3.70, table Sales Line.
The trick with the primay key works.
Cause ... ? I suspect that it happened a few months ago when importing the object as a .txt.

It seems not everybody reading this hread has understood the cause and why the remedy helps, so I try to explain:
At some point in time, MS added the "Clustered" property to the database keys. These versions check the keys of a table object to see whether the property is set for at least one key, and if not, it is set for the primary key automatically.
If you transfer this object to an older system as a fob, that property is still there, but the system does not know what it is and ignores it. Since it does not know it, there is also no UI to modify or delete it.
When you try to export that object in that older client to text, the system is no longer able to ignore it (without modifying the object in case you reimport the text version) and displays the error.
When you detele the key with the Clustered property set, the property is deleted along with it. If you recreate the key in that older client the problem is gone.
As I wrote before, another way to avoid he problem is to clear the Clustered property on all keys on the later client before you create the fob for transfer to an earlier client.

And the moral of the story: Do not transfer objects to older versions! [-X

Howdy, Stranger!

Quick Links

Categories

the type 4994 was not defined for the function

Answers