Discussione:
Lentezza DB 2003 query di accodamento
(troppo vecchio per rispondere)
esseAemme
2010-01-11 17:05:39 UTC
Permalink
Ciao a tutti,

ho fatto un db in access 2003 che da qualche mese, in fase di query di
accodamento è diventato lentissimo.

E' diviso in backend e frontend.

Il be pesa 2,69MB, e pensavo che il problema fosse per il fatto che
era salvato in rete, e il server stesso è lento.
In realtà ora l'ho copiato in locale... e mannaggia ci mette veramente
4 ore per fare un accodamento di record.

La tabella nella quale devo accodare i dati contiene quasi 16.000
record, e i record da accordare sono circa un centinaio alla volta...
ma veramente non mi spiego il problema di lentezza? ?? O_o o_O

Se questa operazione la faccio a mano in un attimo è fatta, ma quando
si tratta di utilizzare la query lì si presentano i problemi.

Secondo voi è un problema di dimensioni database... oppure della
query?

Grazie 1000 in anticipo e buona serata

:)

Sam & Sara 23+1
esseAemme
2010-01-12 08:47:12 UTC
Permalink
On 11 Gen, 18:05, esseAemme <***@gmail.com> wrote:
Scusate, volevo solo aggiungere, che questa mattina ho lanciato la
funzionalità di compatta e ripristina database, e la cosa mi manda in
tilt access, resta in attesa una vita e si blocca... il fatto che l'ho
sempre fatto e non mi dava questi problemi...

Non riesco a capire cosa stia succedendo...

Ciao e grazie
Sam
esseAemme
2010-01-12 10:50:46 UTC
Permalink
On 12 Gen, 09:47, esseAemme <***@gmail.com> wrote:
Eccomi con aggiornamenti, ho verificato tutta la procedura che ho
scritto, e l'inghippo si verifica sulla query che prende i dati da una
tabella temporanea e li incolla nella tabella listino materie prime.

Questa è la query incriminata che ci mette una vita e resta nel limbo:

Que5 Q_ACC_Temp_TBLCSTMPeVS_To_CSTMP_Cliente
INSERT INTO TBL_CSTMP ( cstmp_mpid, cstmp_costo, cstmp_perc,
cstmp_vsid )
SELECT Temp_TBLCSTMP.cstmp_mpid, Temp_TBLCSTMP.cstmp_costo,
Temp_TBLCSTMP.cstmp_perc, TBL_VSCSTMP.vscstmp_id
FROM Temp_TBLCSTMP, TBL_VSCSTMP
WHERE (((Temp_TBLCSTMP.cstmp_mpid) Not In (select cstmp_mpid from
TBL_CSTMP)) AND ((TBL_VSCSTMP.vscstmp_data)=Date())) OR
(((TBL_VSCSTMP.vscstmp_id) Not In (select cstmp_vsid FROM TBL_CSTMP))
AND ((TBL_VSCSTMP.vscstmp_data)=Date()));


Mi sapreste dare qualche suggerimento?

Grazie in anticipo e buon lavoro a tutti
Sam
Alessandro Cara
2010-01-12 11:32:19 UTC
Permalink
Post by esseAemme
Eccomi con aggiornamenti, ho verificato tutta la procedura che ho
scritto, e l'inghippo si verifica sulla query che prende i dati da una
tabella temporanea e li incolla nella tabella listino materie prime.
Que5 Q_ACC_Temp_TBLCSTMPeVS_To_CSTMP_Cliente
INSERT INTO TBL_CSTMP ( cstmp_mpid, cstmp_costo, cstmp_perc,
cstmp_vsid )
SELECT Temp_TBLCSTMP.cstmp_mpid, Temp_TBLCSTMP.cstmp_costo,
Temp_TBLCSTMP.cstmp_perc, TBL_VSCSTMP.vscstmp_id
FROM Temp_TBLCSTMP, TBL_VSCSTMP
WHERE (((Temp_TBLCSTMP.cstmp_mpid) Not In (select cstmp_mpid from
TBL_CSTMP)) AND ((TBL_VSCSTMP.vscstmp_data)=Date())) OR
(((TBL_VSCSTMP.vscstmp_id) Not In (select cstmp_vsid FROM TBL_CSTMP))
AND ((TBL_VSCSTMP.vscstmp_data)=Date()));
Mi sapreste dare qualche suggerimento?
Si fai in modo che non ci siano le "not in"
--
ac
esseAemme
2010-01-12 14:27:33 UTC
Permalink
Post by Alessandro Cara
Si fai in modo che non ci siano le "not in"
--
ac-
Buongiorno Alessandro,
in effetti mi sono accorta solo ora che quelle not in in effetti sono
inutili, perchè faccio già dall'inizio delle procedure di controllo
che quando arrivo all'accodamento dei dati, è impossibile che ci siano
duplicati.

Quello che faccio ora è l'esecuzione in serie delle seguenti query:

Que1 -> inserisce la nuova versione di listino (funziona e se serve ve
la copio)
Que2 -> crea una nuova tabella copiando i dati relativi alla versione
di listino visualizzata nella finestra
Que6 -> accodo il contenuto della tabella temporanea nella tabella
listino materie prime


Que2
SELECT TBL_CSTMP.cstmp_mpid, TBL_CSTMP.cstmp_costo,
TBL_CSTMP.cstmp_perc INTO Temp_TBLCSTMP
FROM TBL_CSTMP
WHERE (((TBL_CSTMP.cstmp_vsid)=[forms]![msc_cstmp]!
[versionelistino]));



Que6
INSERT INTO TBL_CSTMP ( cstmp_mpid, cstmp_costo, cstmp_perc,
cstmp_vsid )
SELECT Temp_TBLCSTMP.cstmp_mpid, Temp_TBLCSTMP.cstmp_costo,
Temp_TBLCSTMP.cstmp_perc, Q_VERSIONELISTINO.vscstmp_id
FROM Temp_TBLCSTMP, Q_VERSIONELISTINO;



A questo punto però mi da una violazione di chiave.

Dice "Impossibile accodare tutti i record nella query di accodamento"
Numero di record non aggiunti alla tabella a causa di violazioni di
chiave: 96

Quello che non c'è nella query di accodamento è il campo chiave
primaria della tabella TBL_CSTMP.cstmp_id, è per questo che mi da
l'errore? Non dovrebbe, in fase di accodamento creare autonomamente la
chiave primaria?

Grazie ancora in anticipo e buon lavoro
Samantha
esseAemme
2010-01-12 14:38:34 UTC
Permalink
Post by esseAemme
Post by Alessandro Cara
Si fai in modo che non ci siano le "not in"
--
ac-
Buongiorno Alessandro,
in effetti mi sono accorta solo ora che quelle not in in effetti sono
inutili, perchè faccio già dall'inizio delle procedure di controllo
che quando arrivo all'accodamento dei dati, è impossibile che ci siano
duplicati.
Que1 -> inserisce la nuova versione di listino (funziona e se serve ve
la copio)
Que2 -> crea una nuova tabella copiando i dati relativi alla versione
di listino visualizzata nella finestra
Que6 -> accodo il contenuto della tabella temporanea nella tabella
listino materie prime
Que2
SELECT TBL_CSTMP.cstmp_mpid, TBL_CSTMP.cstmp_costo,
TBL_CSTMP.cstmp_perc INTO Temp_TBLCSTMP
FROM TBL_CSTMP
WHERE (((TBL_CSTMP.cstmp_vsid)=[forms]![msc_cstmp]!
[versionelistino]));
Que6
INSERT INTO TBL_CSTMP ( cstmp_mpid, cstmp_costo, cstmp_perc,
cstmp_vsid )
SELECT Temp_TBLCSTMP.cstmp_mpid, Temp_TBLCSTMP.cstmp_costo,
Temp_TBLCSTMP.cstmp_perc, Q_VERSIONELISTINO.vscstmp_id
FROM Temp_TBLCSTMP, Q_VERSIONELISTINO;
A questo punto però mi da una violazione di chiave.
Dice "Impossibile accodare tutti i record nella query di accodamento"
Numero di record non aggiunti alla tabella a causa di violazioni di
chiave: 96
Quello che non c'è nella query di accodamento è il campo chiave
primaria della tabella TBL_CSTMP.cstmp_id, è per questo che mi da
l'errore? Non dovrebbe, in fase di accodamento creare autonomamente la
chiave primaria?
Grazie ancora in anticipo e buon lavoro
Samantha
Nulla, ho modificato la Que2 e la Que6 includendo anche il campo
chiave primaria, ma mi da sempre lo stesso errore di violazione. Ecco
le due query come sono state modificate:

Que2
SELECT TBL_CSTMP.cstmp_id, TBL_CSTMP.cstmp_mpid,
TBL_CSTMP.cstmp_costo, TBL_CSTMP.cstmp_perc INTO Temp_TBLCSTMP
FROM TBL_CSTMP
WHERE (((TBL_CSTMP.cstmp_vsid)=[forms]![msc_cstmp]!
[versionelistino]));

Que6
INSERT INTO TBL_CSTMP ( cstmp_id, cstmp_mpid, cstmp_costo, cstmp_perc,
cstmp_vsid )
SELECT Temp_TBLCSTMP.cstmp_id, Temp_TBLCSTMP.cstmp_mpid,
Temp_TBLCSTMP.cstmp_costo, Temp_TBLCSTMP.cstmp_perc,
Q_VERSIONELISTINO.vscstmp_id
FROM Temp_TBLCSTMP, Q_VERSIONELISTINO;

mi sa che mi sto perdendo in un bicchier d'acqua... sgrunt

:)
esseAemme
2010-01-13 14:16:23 UTC
Permalink
Post by esseAemme
Post by esseAemme
Post by Alessandro Cara
Si fai in modo che non ci siano le "not in"
--
ac-
Buongiorno Alessandro,
in effetti mi sono accorta solo ora che quelle not in in effetti sono
inutili, perchè faccio già dall'inizio delle procedure di controllo
che quando arrivo all'accodamento dei dati, è impossibile che ci siano
duplicati.
Que1 -> inserisce la nuova versione di listino (funziona e se serve ve
la copio)
Que2 -> crea una nuova tabella copiando i dati relativi alla versione
di listino visualizzata nella finestra
Que6 -> accodo il contenuto della tabella temporanea nella tabella
listino materie prime
Que2
SELECT TBL_CSTMP.cstmp_mpid, TBL_CSTMP.cstmp_costo,
TBL_CSTMP.cstmp_perc INTO Temp_TBLCSTMP
FROM TBL_CSTMP
WHERE (((TBL_CSTMP.cstmp_vsid)=[forms]![msc_cstmp]!
[versionelistino]));
Que6
INSERT INTO TBL_CSTMP ( cstmp_mpid, cstmp_costo, cstmp_perc,
cstmp_vsid )
SELECT Temp_TBLCSTMP.cstmp_mpid, Temp_TBLCSTMP.cstmp_costo,
Temp_TBLCSTMP.cstmp_perc, Q_VERSIONELISTINO.vscstmp_id
FROM Temp_TBLCSTMP, Q_VERSIONELISTINO;
A questo punto però mi da una violazione di chiave.
Dice "Impossibile accodare tutti i record nella query di accodamento"
Numero di record non aggiunti alla tabella a causa di violazioni di
chiave: 96
Quello che non c'è nella query di accodamento è il campo chiave
primaria della tabella TBL_CSTMP.cstmp_id, è per questo che mi da
l'errore? Non dovrebbe, in fase di accodamento creare autonomamente la
chiave primaria?
Grazie ancora in anticipo e buon lavoro
Samantha
Nulla, ho modificato la Que2 e la Que6 includendo anche il campo
chiave primaria, ma mi da sempre lo stesso errore di violazione. Ecco
Que2
SELECT TBL_CSTMP.cstmp_id, TBL_CSTMP.cstmp_mpid,
TBL_CSTMP.cstmp_costo, TBL_CSTMP.cstmp_perc INTO Temp_TBLCSTMP
FROM TBL_CSTMP
WHERE (((TBL_CSTMP.cstmp_vsid)=[forms]![msc_cstmp]!
[versionelistino]));
Que6
INSERT INTO TBL_CSTMP ( cstmp_id, cstmp_mpid, cstmp_costo, cstmp_perc,
cstmp_vsid )
SELECT Temp_TBLCSTMP.cstmp_id, Temp_TBLCSTMP.cstmp_mpid,
Temp_TBLCSTMP.cstmp_costo, Temp_TBLCSTMP.cstmp_perc,
Q_VERSIONELISTINO.vscstmp_id
FROM Temp_TBLCSTMP, Q_VERSIONELISTINO;
mi sa che mi sto perdendo in un bicchier d'acqua... sgrunt
:)- Nascondi testo citato
- Mostra testo citato -
Buongiorno a tutto l'ng :)

volevo solo avvisarvi che alla fine ho risolto il tutto.

Come indicato da Alessandro Cara le Not In erano l'origine dei miei
grattacapi. Già a monte compio delle verifiche e quelle clausole NOT
IN erano veramente in più e non servivano.

L'errore indicato successivamente, era causato da una anomalia sulle
relazioni, non ho capito come sia successo ma si era aggiunta una
relazione ... che mi mandava in tilt le query di accodamento anche se
le stesse erano corrette.

Sistemato quello ha ricominciato a funzionare il tutto, con mia somma
gioia :D

Ciao
Samantha
Alessandro Cara
2010-01-13 16:33:23 UTC
Permalink
esseAemme ha scritto:
[cut]
Post by esseAemme
Sistemato quello ha ricominciato a funzionare il tutto, con mia somma
gioia :D
Ho visto solo ora il 3D e la sua "gioiosa" conclusione ;-{)
--
ac

Continua a leggere su narkive:
Loading...