Jump to content


Photo
- - - - -

INVALID DATA TYPE FOR SQL


1 reply to this topic

#1 Albert Ho

Albert Ho

    Member

  • Members
  • PipPip
  • 19 posts
  • Gender:Male

Posted 22 April 2003 - 01:54 AM

I have recently upgraded my PROIV kernel from 5.5 build 401 to 5.5 build 407. Since then I've been facing this problem

SQL Level
368 - SQL ERROR : INVALID DATA TYPE FOR SQL

PROIV Level
filedef=FILEXXX Mismatch - regen required

I have install the build 407 bootstrap onto my existing PROIV bootstrap directory (build 401). I've been doing this way of upgrading since the last 2 builds of PROIV 5.5, and it seems to be fine until in this one.

:huh:

#2 DARREN

DARREN

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 396 posts
  • Gender:Male
  • Location:Florida,USA

Posted 24 April 2003 - 03:35 AM

In simple terms PROIV keeps an image of a file definition in memory. A check was implemented into the Kernel that basically said that if a file definition changes, (or the kernel thought it had changed) by going into the file definition maintenance, the file definition was 'unsafe'. The absence of this check was causing "thread exceptions". What complicates matters is that there is a 'bit' that instructs the kernel to reload the file image into memory upon change (note: change may mean that you just went into the file maintenance screen in change mode and committed out without actually making any changes). This bit is correctly being set via @CREATEU (the old native file regen util) but was missed out from the re-write (@CREATE1). The latter being the one that is employed by Studio/VIP. This bug has been fixed and will be released as part of the next maintenance release of VIP/Studio (i am told). I think this bit is by session, so even if it is set so that the file image reloads into memory, other sessions may not see it and will have to log off and on again to flush the memory image.

In a live environment the check makes sense, as file definitions should not be changing. In a development environment the check is a little more questionable. I am aware of a switch that turns the check off but it is more than my job is worth to expose it. I am also aware that the check has been enhanced (made more intelligent) so that even if the "switch is off”, the kernel makes basic checks. All am I providing is an explanation on 'why' you are getting this, rather than how to make it go away.

ps I think the version you gave was the client version and not the kernel version.
Things should be made as simple as possible, but not simpler



Reply to this topic



  


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users