Esportare Base in server

[UTPiovene]

Si, adesso funziona tutto . Il problema è che non so come ho fatto di preciso
Appena riesco a capire come ho fatto riepilogo tutta la procedura.

[UTPiovene]

Ho portato quasi tutti i miei database in H2.
In uno riscontro un fatto fastidioso: la numerazione progressiva automatica del campo ID non aumenta di 1 ma di 30 (è passato da 438 a 468).
Avevo già riscontrato tale problema tempo fa (forse sullo stesso database?), senza trovare la soluzione.
Ho il dubbio che possa essere un problema di collegamenti fra dati di tabelle diverse.
In ogni caso gli altri database funzionano egregiamente e senza problemi.
Ho già anticipato che H2 funziona come MySql, dove si possono creare vari "Schema" (cioè gruppi di tabelle che compongono il database) all'interno dello stesso file.
Il vantaggio è che se servono i dati di una tabella in vari "schemi", non occorre ripetere la medesima tabella per ogni schema, ma si fa riferimento sempre alla stessa già esistente, con notevole risparmio di tempo, dati sempre aggiornati ed omogenei.

[vladko]

stesso problema con H2 o con altro?
si vorrei dire che già ho sentito questo problema,mi sembra con mysql e ora cerco nella mia "profonda mente"

[UTPiovene]

Per completezza di informazione non è stata data nessuna istruzione per un incremento diverso da 1. Lo fa di sua iniziativa

[Mizio1961]

Ciao
Vladko ricorda bene, ho partecipato anch'io a quel post tempo fa (primi mesi del 2012)
A volte il problema nasce dalle 'capacità' di gestori di banche dati piuttosto 'rozzi', in grado di fare delle 'compattazioni' dei dati.
La compattazione è un modo pulito per dire che il programma di gestione dei dati è incompleto, mancando delle funzioni interne di controllo e rimozione di tali 'buchi'.
Nei buchi restano i residui di record cancellati o corrotti e i campi di tipo contatore sono i primi testimoni di tali anomalie.
Ecco uno dei perchè a volte nel trasferimento dei dati da un db a un altro accadono questi fatti sgraditi.
Anche l'integrità referenziale fra tabelle può essere la causa di questi problemi e chi più ne ha più ne metta.
Ecco perchè anche nell'altro post ho concluso dicendo che sarebbe meglio evitare l'uso dei campi contatore o limitarlo al minimo, senza comunque dare un valore eccessivo alla precisione del loro contenuto e affidando i compiti più importanti a campi numerici il cui incremento sia controllato tramite macro e implementazioni personali verificabili.
Questo solo per dare un contributo alla discussione, senza voler fare 'il professore' come si dice dalle mie parti...
Saluti by Mizio

[UTPiovene]

Al prossimo inserimento di dati potrò verificare se il buco è dovuto a dati non registrati e contatore incrementato comunque. Anche se tendo a dire subito che un salto di 30 non può essere dovuto a dati inseriti male o cancellati.
Già un altro database (o forse questo stesso?) in precedenza mi aveva dato tali problemi incrementando invece che di 1 ogni volta di 30 o più.
L'incremento tramite macro lo potrei anche fare, ma se poi si "incasina" la macro? Non so se poi sarei capace di sistemarla.
Incrementare a mano, oltre ad essere una rottura che si potrebbe evitare, darebbe adito ad altri problemi di gestione visto che il database è utilizzato da più persone e non tutti con un minimo di dimestichezza.
Io tendo a pensare che sia un problema di collegamenti fra tabelle. E' possibile che siano quelli delle query? Altre relazioni non ne ho.

[UTPiovene]

Ho inserito un nuovo record di dati e questa volta il salto è stato di 32 anzichè 30