[Koha] stack number cannot be stored in Koha 21.05

[Katrin Fischer]

Hi Michael,

ah ok, that was a local change then?

Because it looks like it has always been tinyint:

https://git.koha-community.org/Koha-community/Koha/src/branch/master/installer/data/mysql/kohastructure.sql#L3015

https://git.koha-community.org/Koha-community/Koha/src/branch/18.11.x/installer/data/mysql/kohastructure.sql#L932

https://git.koha-community.org/Koha-community/Koha/src/branch/3.2.x/installer/data/mysql/kohastructure.sql#L994

varchar should work on database side, I am not aware of a code side
check, but there could be one. Anything helpful in the logs maybe?

Maybe worth checking if deleteditems was altered as well.

Katrin

|
|


On 06.10.21 21:39, Michael Kuhn wrote:
> Hi Katrin
>
> > 952$j is mapped to items.stack by default that has the datatype
> > tinyint(1) in the database. A common problem I have encountered here
> > is that it won't save when you try to store something non-numeric or
> > outside the range of tinyint. Could that be the issue?
>
> Yes, this would indeed be a problem... Thank you very much for the hint!
>
> Our library was working with Koha 18.11 before - where it was possible
> to store content like "m011577".
>
> Looking into http://schema.koha-community.org/18_11/tables/items.html
> shows that in this version the datatype was BIT(0) which seems to mean
> mean "tinyint". In my Koha 21.05 demo installation I see it actually
> is "tinyint".
>
> However when asking the actual Koha 21.05 library database the
> datatype is given as "varchar"!
>
> So it seems like someone has unscrupulously changed the datatype of
> this field in the past (a very bad idea). But then again - shouldn't
> the database accept value "m011577" when the datatype is "varchar"? At
> least in Koha 18.11 it seems to have worked.
>
> I was able to successfuilly insert "011577". But not "m011577". Is
> there maybe a script that checks if the values are of the correct
> datatype when trying to store anything in the database? Maybe the guy
> responsible for this problem also changed the datatype in such a script?
>
> Best wishes: Michael