- 227
- 20
- CPU
- AMD Athlon - X86_64
- Scheda Madre
- Acer RS780HVF
- HDD
- SSD PLUS da 240GB (ospita 3 S.O Linux), WDC WD10EFRX-68F da 1000GB (ospita solo archivi dati)
- RAM
- n.2 DDR" per 2GB
- OS
- fedora 28 Mate, Ubuntu Mate, Linux Mint 19
Come già detto in altre occasioni,per l'archiviazione utilizzo database SQLite.
Di tanto in tanto, allo scopo di velocizzare le mie modeste applicazioni in linguaggio Gambas o Java, quest'ultimo da circa un anno, cerco nuove soluzioni con l'attivazione di funzioni SQLite non impiegate prima.
Ieri, per es. ho cominciato a modificare una parte di programma, scritto in Gambas, in cui copio le singole tabelle del DB in altrettante tabelle provvisorie, riordinandone fisicamente i record all'interno di ciascuna. Durante la trascrizione risequenzio, a partire da 1, la chiave primaria della tabella.
Ho scoperto che potevo fare praticamente lo stesso lavoro eseguendo:
e in appena 00:00:04 secondi la tabella transitoria è copiata con tutti i record più recenti, secondo le mie necessità.
Poi ho eseguito
con cui ho cancellato la tabella di partenza e rinominato la tabella transitoria, in modo da restituirle definitivamente il nome originario.
Contentissimo, sono andato a controllare, prima di ripetere il lavoro anche sulle altre tabelle del DB, la struttura dati della tabella. L'ho trovata inalterata, tranne che per la chiave primaria:
Vorrei capire da che cosa può dipendere tutto ciò e come potrei restituire la tipologia di primary key ed ottenere la numerazione progressiva numerica crescente per la colonna "IdCauFreq".
Di tanto in tanto, allo scopo di velocizzare le mie modeste applicazioni in linguaggio Gambas o Java, quest'ultimo da circa un anno, cerco nuove soluzioni con l'attivazione di funzioni SQLite non impiegate prima.
Ieri, per es. ho cominciato a modificare una parte di programma, scritto in Gambas, in cui copio le singole tabelle del DB in altrettante tabelle provvisorie, riordinandone fisicamente i record all'interno di ciascuna. Durante la trascrizione risequenzio, a partire da 1, la chiave primaria della tabella.
Ho scoperto che potevo fare praticamente lo stesso lavoro eseguendo:
Codice:
sql1 = "CREATE TABLE causalifreq2 AS SELECT * from causalifreq WHERE DtUltCausFreq > '" & CalcData60GGfa.iData60GGfa & "' ORDER BY DtUltCausFreq"
Try ApriDB.DBConnection.EXEC(sql1)
Poi ho eseguito
Codice:
Try ApriDB.DBConnection.EXEC("DROP TABLE causalifreq")
ApriDB.DBConnection.EXEC("ALTER TABLE causalifreq2 RENAME To causalifreq")
Contentissimo, sono andato a controllare, prima di ripetere il lavoro anche sulle altre tabelle del DB, la struttura dati della tabella. L'ho trovata inalterata, tranne che per la chiave primaria:
Il campo "IdCauFreq" non è più una chiave primaria, inoltre i codici numerici, all'interno della rispettiva colonna non seguono più una numerazione progressiva.`IdCauFreq` INTEGER PRIMARY KEY AUTOINCREMENT <--- prima delle istruzioni di trascrizione e rinominazione
`IdCauFreq` INT <--- a fine lavoro
N.Progr.Riga IdCauFreq DtUltCausFreq OraUltCausFreq 1 225 20190820 220101 2 226 20190820 220945 3 228 20190821 213453 4 229 20190822 213213 5 230 20190822 213256 6 105 20190824 212720 7 231 20190824 212445 ... ... ... ... 13 237 20190826 214551 14 173 20190827 213938 15 36 20190828 213152 16 89 20190829 213959 17 238 20190830 213503 18 239 20190830 213743 19 122 20190831 213411 20 240 20190831 215116
Vorrei capire da che cosa può dipendere tutto ciò e come potrei restituire la tipologia di primary key ed ottenere la numerazione progressiva numerica crescente per la colonna "IdCauFreq".