I am not complete sure if I understand your problem.
Does it mean your issues are not numbered 1,2,3,4, ... but something like 1,4,7,10, ...?

If so and if you are using MySQL, check database auto_increment settings.
Do this by running the following statement SHOW VARIABLES LIKE 'auto_inc%' ;

Hello, thank you for your quick response. but the problem is that he is numbering well, with the consecutive one at a time, but from one moment to the next he increases the numbering, for example he jumps from 192 to 196 and the numbers 193-194-195 are lost and when looking for them He says they do not meet. If I use MYSQLExpress. I appreciate your guidance.

for example he jumps from 192 to 196 and the numbers 193-194-195 are lost

Isn't this what I wrote before?

but something like 1,4,7,10,

What's the output of SHOW VARIABLES LIKE 'auto_inc%' ; ?

If all displayed values are 1, you have to provide the additional information listed below

• Exact version ofPHP, Database, Web server, Browser and Operating System
• Relevant customizations (e.g. changes in config_inc.php, etc)
• Installed plugins or custom functions ?
• Was the MantisBT source code modified in any way ?

• Exact version of PHP, 7.1.7 Database, IIS Web server, Browser Chrome and Operating System Windows Server 2012
• Relevant customizations (e.g. changes in config_inc.php, etc). Only custom fields and customizations of the Mantis and time zone were added.
• Installed plugins or custom functions? you do not have plugins installed.
Was the MantisBT source code modified in any way? The source code was not modified.
. I do not know how to run SHOW VARIABLES LIKE 'auto_inc%'; Can you tell me how to execute it?

Thanks

Still missing a clear information about your database.
Is it MySQL?
If so, you should execute the statement in the MySQL client you are using (mysql command line, phpMyAdmin, MySQL Workbench, ...)

Is SQLEXPRESS

Sorry I can't help as I don't use this database.

I recommend to use MySQL or MariaDB as most of the Mantis developers and users are using it.

I appreciate your collaboration, guidance and the time you have dedicated me. have a happy day.

Hello,

This not a MantisBT issue. The sequence numbers are assigned by the RDBMS. I believe you're most likely facing a known issue with SQL server, see

https://stackoverflow.com/questions/14146148/identity-increment-is-jumping-in-sql-server-database

I'm sorry, but there is absolutely nothing that we can do about it.

Also, please note that having non-sequential issue IDs is technically not a problem - The ID is just that - a unique identifier; you would also have gaps e.g. if you have multiple projects (issues are unique across the whole instance) or if you delete issues.

@dregad all you said about non-sequential Ids is right, but the stackoverflow link
describes a well known issue with identity caching and sqlserver restarts, and I think
is unrelated to the issue Jose has (those jumps are +1000). This looks more like a
problem with concurrent submits, due to a misconfiguration (IIS, PHP, FastCGI) or a
deeper problem on the db api level. I never had such a problem in a comparable
environment, but I am the only user. Will try to simulate concurrent submits over the
weekend and check whats happening then.

Jose could you please provide additional info about:

1. SQLSERVER (EXPRESS) Version
2. IIS Version
3. PHP Version (32/64, ts/nts), FastCGI?
4. Does this only happen when several users submit issues simultaneously?
5. Is this only a "id counting" problem or are issues lost, wrongly linked?
6. Are there any abnormalities in the bug or bug_text table (use SSMS to check) for your jumps?

Dregad and obmsch, I appreciate your interest in supporting me and in your effort to try to solve my problem.

attached the requested information:

1.SQLSERVER (EXPRESS) Version: SQL 2012 Express.
2.IIS Version: IIS 8.5
3.PHP Version (32/64, ts / nts), FastCGI? 7.1.7 64 BITS 4. .Does this happen when several users submit issues simultaneously ?: I have not been able to determine if it is when there are several users connected or registering. The truth is that there are always several users connected to the time verifying their cases.
5.Is this only a "id counting" problems or are lost issues, wrongly linked ?: No problems are lost that are already registered, it's just that the consecutive ID is skipped, sometimes 1 or sometimes 4 consecutive times.
6.Are there any abnormalities in the bug or bug_text table (use SSMS to check) for your jumps? there is none

Again to the two thanks for all your bearings.

Jose, as said I will try to reproduce what you are seeing in my environment, but
I am not sure about your answer to my question 5:

5.Is this only a "id counting" problems or are lost issues, wrongly linked ?: No
problems are lost that are already registered, it's just that the consecutive ID
is skipped, sometimes 1 or sometimes 4 consecutive times.

You are talking about already registered issues, I was asking for new submits (issues)
I have no idea about the environment your tracker is running in (internal/external),
but do you have any feedback from users having problems to submit a new issue?
Are the jumps equally observable on related tables (bug_text)? Are there any
entries in bug_text not referenced in bug?

Completed run tests with the following setup:
Win10(1709), IIS10, MSSQLEXPESS 2016, PHP7.1.16, MantisBT 2.13.1, php_sqlsrv 5.2.0
Created project 'RestTest' and four users 'restuser1'..'restuser4' (all reporters)
with api tokens. Concurrently run a rest client application for each of them, submitting
1000 issues in a loop (sums up to 4000).
Result: All issues created with consecutive ids, no gaps/jumps.

Setting up the test environment I ran in a couple of problems. I put them here and let
the devs decide how to proceed.

1. htaccess equivalant web.config for IIS is missing in api/rest

   <?xml version="1.0" encoding="UTF-8"?>
   <configuration>
   <system.webServer>
   <rewrite>
     <rules>
       <rule name="imported rule" stopProcessing="true">
         <match url="^" ignoreCase="false" />
         <conditions>
           <!--# Based on Slim Framework recommendation @ http://docs.slimframework.com/routing/rewrite/-->
           <add input="{REQUEST_FILENAME}" matchType="IsFile" ignoreCase="false" negate="true" />
         </conditions>
         <action type="Rewrite" url="index.php" appendQueryString="true" />
       </rule>
     </rules>
   </rewrite>
   </system.webServer>
   <location allowOverride="true"/>  
   </configuration>

2. I don't use email notification, but my config_inc.php was lacking '$g_enable_email_notification = OFF;'.
   This completely stalled MantisBT and I got 'timeouts' in the rest client application after an arbitrary
   number of submitted issues. Alas this is a configuration problem, the api should handle this more
   gracefully.

htaccess equivalant web.config for IIS is missing in api/rest

Follow-up in 0024347

'timeouts' in the rest client application after an arbitrary number of submitted issues

Just to be sure, you was that due to the e-mail queue filling up and not being processed ?

@dregad the rest request time out (iis time out). Looked like internal processing doesn't finish. The email table
had 30 or so entries at that point. For me myself notifications were off ($g_email_receive_own = OFF;), so I didn't
encounter that before.

Setting to resolved as this is not a Mantis but a database issue.

Thanks @obmsch for your support.