Security module --> Creating sec_settings Specified key was too long; max key length is 1000 bytes

Scriptcase 9 Bugs
#1

Hello ,
I’m using very last version of SC 9.11.013 (2) and I’m trying to create a security module (Group) . I’m using mysql 8.0.31 on wampserver .
The error I always got is the following.

ERROR

Creating sec_settings

Specified key was too long; max key length is 1000 bytes

A part from the question about why Security module must to use so big keys …
does anyone can help me fix this annoying issue that stuck me ?
Thanks

#2

what database you running on WAMP ? what database driver have you choosed in project connection settings ?

#3

It was a temporary error . Now it works as usual

#4

I am getting the same Error now. What did you do to fix this ?

#5

I’m sorry , I really forgot everything…
Security model could be nice but the one has developed put some strange control and code inside it.

#6

check these items:

  1. the storage type for tables have ti be is InnoDB (not MyISAM )
  2. the collate for strings is utf8mb4, change it to utf8 ( if you can use utf8 ) so the bytes for the index is under the limit

Vincenzo

#7

When the new Security Module is created the SC creates tables and there is no option to select the dB engine,so in most cases the statements about the InnoDB are irrelevant. It only matters if the user chas changed the engine or uses some existing tables, but then he would use different options when creating SEC.MOD. in SC.
As of today (Jan-2026) the security module does not work with MySQL/MariaDB on my end. I am still unsure if it is a local problem or SC bug. I tried to create several SC Demo Projects, then add SEC.MOD and got into the same errors about the keys,…

#8

Thanks for suggestions.
I normally use MySQL/MariaDB too and that’s probably the main issue.
I think also that the SC. security module has some nice parts but also a lot of old and buggy stuff and strange code. I don’t like also the attitude to have separate forms about create, edit, delete.

#9

this is a copy of an Email I’ve sent today to NETMAKE

============================================================
The entire security database structure is wrongly designed :frowning: and that causes endless problems.

It should be redesigned and recreated. Main problem are the Primary Keys. This structure has not been changed for 20 years !

The main problem is that you do not use Numerical fields to keep the index and primary keys. This not only slows down data processing, but also causes key string length issues (like the one we’re dealing with). When I see this design, I really want to scream. 99% of forum users made the same statements about this BAD DESIGN :frowning:

Each user should have an ID field (LONG Int, 11) and Primary Key base on this field. Then everything would be easier. The idea of using STRINGS for primary keys is only OK for small size tables and places where performance is unimportant. Tables relationships should be built on the principle of primary key, always using numeric values. I have learned this 40 years ago and this is like knowing what is voltage for the electrician.

I really do not understand how can you keep this bad structure for so many years and waste time on problems it is causing.

PLEASE SHARE THIS WITH YOUR MANAGERS

#10

Basically for anybody using MySQL, security module creation is TRASH. It will simply cause errors and will not allow to create tables. NETMAKE posted an SQL script to create tables manually, but this script also results errors. This is really a disaster :frowning:

I am waiting 3+ weeks for a fix and so far nothing.

#11

There is no option to set the storage engine in SC. Your suggestion is irrelevant, unless somebody can change default engine on the server (and most users cannot, unless they are running some form of VPS).