Newsgroup: it.comp.lang.delphi
Titolo: Reset del campo ad autoincremento in Paradox

Il Pack per Paradox lo puoi fare con la DbiDoRestructure (Api del BDE).
Per azzerare l'autoinc dovrebbe bastare il pack subito dopo aver svuotato la
tabella...
C'era anche chi lo convertiva in ftIntegerField, lo azzerava e lo rimetteva
a ftAutoinc, oppure lo eliminava e ricreava a Run-Time...
Io personalmente evito di usare gli autoinc: troppi problemi (soprattutto in
rete)...
Ciao :-)
--
(¯`·.¸¸.·´¯`·.¸¸.-> Andrea <-.¸¸.·´¯`·.¸¸.·´¯)
AntiSpam: rimuovere il trattino basso dall'indirizzo per rispondere
AntiSpam: remove the underscore from the e-mail address to reply

E' mai capitato a nessuno?
non è la prima volta che qualcuno chiede come risolvere questo problema.
Se si trattava di un indice, potevi cancellarlo e ricrearlo.
In questo caso potresti crearti la tabella a run-time definendo campi ed
eventuali indici.
In questo modo stai sicuro che sorvoli il problema del campo
autoincrementale.
Oppure la volta passata avevo pensato di utilizzare una soluzione non molto
pulita ma funzionale.
La tua tabella rimane la stessa (cioè non la ricrei a run-time) ma tramite
TFileStream o un' altra funzione per l'accesso ai file, vai a modificare i 4
byte (che ti devi cercare) che identificano il valore del campo
autoincrementale.
Visto che la tabella è vuota i byte stanno per forza nella testata del file
paradox. Ok ?
Per cercare i 4 byte, prendi un editor esadecimale e cerca il valore attuale
del campo autoincrementale.
Supponiamo che in quel momento l'ultimo valore del campo autoincrementale
era 100, tu dovrai cercare
64 00 00 00.
Guarda la posizione che occupa e poi inventati un sistema per settare quei 4
byte a 0.
In pratica ti sposti a quella posizione e scrivi su file una variabile
Integer inizializzata a 0.
Nel file dovrebbe risultare 00 00 00 00 invece di 64 00 00 00.
Se ci sono dubbi scrivi pure. Non garantisco che la soluzione funziona al
100%. Cioè io l' avevo provata ed effettivamente il campo autoincrementale è
ripartito da 1.
Ti saluto......ciao !!
Antonio Tarolla
BSSoftware Tips Mailing - List Support

 non per fare prototipi. ;-))
Scusa, e come gestisci, -in multiutenza- l'inserimento di nuovi record? Con
semafori per evitare che piu' utenti utilizzino la stessa chiave? O, dopo
aver letto l'ultimo record, e aver incrementato il contatore con repeat
try..post..except..errore e incrementa ancora..end until not errore? ma non
e' un po' farragginosa come soluzione?
Ciao, Sandro

:

La prima che hai detto (semafori).
Cmq per cose Quink and Dirty gli autoinc funzionano bene. Per progetti
grossi risparmi tempo a non usarli, tantopiu' che un sistema di semafori
ti serve cmq per impedire incongruenze. Tra parentesi le stesse
considerazioni le applico all'integrita' referenziale e i campi di Lookup
di Px. 
Ciao Uberto

E' mai capitato a nessuno?
la soluzione proposta da FDA dovrebbe funzionare anche se non l' ho provata.
Andrea ti ha suggerito l'API da utilizzare, io invece ho trovato un esempio
pratico di come utilizzarla, così mi sono risparmiato prove varie.
L' esempio fa parte della raccolta DDT (di Cristian Zuddas ) e non credo ci
siano problemi a riportarlo in questo news.
Quindi ecco l' esempio:
Eseguire il Pack di tabelle Paradox e dBASE:
procedure PackTable(Table: TPxTable);
var Props: CURProps;
    hDb: hDBIDb;
    TableDesc: CRTblDesc;
begin
  with Table do
    try
        // Chiusura della tabella e riapertura in modalità esclusiva
      if Active then
        Active := false;
      Exclusive := true;
      Active := true;
        // Acquisizione delle proprietà della tabella per determinazione del
tipo
      Check(DbiGetCursorProps(Handle, Props));
        // Se si tratta di una tabella Paradox, richiama DbiDoRestructure
      if Props.szTableType = szPARADOX then
        begin
            // Ripulisce la struttura
          FillChar(TableDesc, sizeof(TableDesc), 0);
            // Ottenimento dell'handle della tabella
          Check(DbiGetObjFromObj(hDBIObj(Handle), objDATABASE,
hDBIObj(hDb)));
            // Assegnamento del nome tabella al descrittore della tabella
          StrPCopy(TableDesc.szTblName, TableName);
            // Assegnamento del tipo tabella al descrittore della tabella
          StrPCopy(TableDesc.szTblType, Props.szTableType);
            // Impostazione a true dell'opzione PACK
          TableDesc.bPack := true;
            // Chiusura della tabella per completazione della
ristrutturazione
          Active := false;
            // Chiamata a DbiDoRestructure
          Check(DbiDoRestructure(hDb, 1, @TableDesc, nil, nil, nil, FALSE));
        end
      else
          // Se si tratta di una tabella dBASE, richiama semplicemente
DbiPackTable
        if Props.szTableType = szDBASE then
          Check(DbiPackTable(DBHandle, Table.Handle, nil, szDBASE,TRUE))
        else
            // La procedura funziona solo su tabelle Paradox o dBASE
          raise EDatabaseError.Create('La Tabella non è di tipo Paradox o
dBASE');
    finally
        // Chiusura della tabella e rimozione della modalità esclusiva
      Active := false;
      Exclusive := false;
    end;
end;
ti saluto....ciao !!


e' un po' farragginosa come soluzione?
Cmq esiste un componente xGenID (
http://deks.webjump.com/
) che genera
progressivi univoci (anche in multiutenza) su un campo intero.
Si puo' gestire il valore iniziale ecc ecc
Ciao
--
Piero Bonanno
bop...@libero.it
pie...@tiscalinet.it
bop...@tin.it
bpie...@hotmail.com
______________________________________________
"Madame, lei ha tra le gambe uno strumento
che puo' offrire piacere a migliaia di persone,
e tutto quello che sa fare e' grattarlo"
- Sir Thomas Beechan a una violoncellista

 Si puo' gestire il valore iniziale ecc ecc
Lo ho visto. Interessante. Peccato che per usarlo bisogna riscrivere il
motore di gestione dei dati di ogni progetto, il che ne scoraggia l'uso,
almeno per progetti gia' fatti.
Ciao, Sandro