[MSHFlexGrid] Velocità esecuzione TexMatrix(x,y)

[StegcO]

Pardon, pensavo di essermi spiegato, ecco la Query

SELECT Spedizioni.ID, Spedizioni.Dat, Spedizioni.A, Magazzino.Materiale, Spedizioni.Quantita, Spedizioni.Stato, Spedizioni.Corriere, Spedizioni.Notes, Spedizioni.Utente FROM Spedizioni, Magazzino
WHERE Spedizioni.Materiale = Magazzino.ID
ORDER BY Spedizioni.ID DESC

Dove, Spedizioni.Materiale contiene un ID (campo testo nella Tab Spedizioni) che ovviamente corrisponde a un Contatore nella Tab Magazzino relativa a un determinato materiale.

Io vorrei quindi avere una Query risultate la Tab Spedizioni ma con al posto di Spedizioni.Materiale (che è un ID) vorrei il corrispettivo nome del materiale, che vorrei pescare nella Tab Magazzino tramite ID. Però mi da quell'errore

[Brontolo]

Dove, Spedizioni.Materiale contiene un ID (campo testo nella Tab Spedizioni) che ovviamente corrisponde a un Contatore nella Tab Magazzino relativa a un determinato materiale.

Certo, ovviamente. Ma come fa un ID (di tipo Testo ! ) ad avere una corrispondenza con un contatore, quindi numerico ?

StegCo, anche a me piacerebbe essere un astronauta, ma purtroppo non basta che lo scriva nella mia firma.

[TheTruster]

ecco la Query

Quella che hai scritto non è una JOIN e, sinceramente, pensavo che dopo che ti fosse stata consigliata saresti andato almeno a fare qualche ricerca su internet... ma vedo che non l'hai fatto.

Comunque, delle informazioni sulle JOIN le trovi qui: Join (SQL) - Wikipedia

@Spike: Sinceramente apprezzo il tuo interesse e la tua dedizione nel voler comprendere e chiarificare la richiesta... ma d'altro canto sono convinto che, chi chiede aiuto, lo fa per proprio interesse e, per altrettanto proprio interesse, dovrebbe sforzarsi di rendere chiara la sua richiesta arricchendola di dettagli e scrivendo chiaramente in lingua italiana.

TheTruster

[StegcO]

Scusate, ma quindi se io voglio avere una corrispondenza tra due tabelle, come in questo caso, cioè gestire un campo tramite un codice che fa riferimento a una seconda tabella (contente altre informazioni a riguardo) dovrei, nella seconda tabella, NON utilizzare il campo Contatore? e come posso gestire la crezione, per esempio, di un nuovo Record se non ho l'aiuto di un contatore?

Grazie per le info

[spikexx84]

Emhhhh......

Non ta la prendere ma ti mancano decisamente le basi di sql

Pardon, pensavo di essermi spiegato, ecco la Query

SELECT Spedizioni.ID, Spedizioni.Dat, Spedizioni.A, Magazzino.Materiale, Spedizioni.Quantita, Spedizioni.Stato, Spedizioni.Corriere, Spedizioni.Notes, Spedizioni.Utente FROM Spedizioni, Magazzino
WHERE Spedizioni.Materiale = Magazzino.ID
ORDER BY Spedizioni.ID DESC

Dove, Spedizioni.Materiale contiene un ID (campo testo nella Tab Spedizioni) che ovviamente corrisponde a un Contatore nella Tab Magazzino relativa a un determinato materiale.

Io vorrei quindi avere una Query risultate la Tab Spedizioni ma con al posto di Spedizioni.Materiale (che è un ID) vorrei il corrispettivo nome del materiale, che vorrei pescare nella Tab Magazzino tramite ID. Però mi da quell'errore

Allora

Primo errore (grave):

Spedizione.Materiale contiene un ID giusto? Un Id è un numero intero giusto? Perchè mai usi un campo di tipo testo per mettere un Intero?

Cambia il tipo da Testo a Intero Lungo

Secondo errore (apocalitticamente grave)

Evidentemente non sai cos'è una Join e la Join insieme a Select/Update/Delete è la base assoluta delle query sql, non si può lavorare se non si conoscono queste basi, credimi stai perdendo tempo, fermati anche solo un paio di giorni e studia le Join, vedrai che il tempo che ci guadagni poi ti ripagherà di questa scelta, ora ti spiego cosa fa la tua query:

La tua query crea una tabella che abbina a ogni record di Spedizioni tutti i record di magazzino ovvero se Spedizioni contiene 200 Record e Magazzino 20 Record abbiamo un totale di 4000 (non quattrocento quattromila) record nella tua tabella poi prende in esame tutti e 4000 i record e esclude tutti quelli per cui non si verifica la codizione Spedizioni.Materiale = Magazzino.ID riducendo i record a un massimo di 200, il che significa che sono stati creati ed elaborati minimo 3800 record inutili.

Ora esaminiamo la query come dovrebbe esser fatta

SELECT Spedizioni.ID, Spedizioni.Dat, Spedizioni.A, Magazzino.Materiale, Spedizioni.Quantita, Spedizioni.Stato, Spedizioni.Corriere, Spedizioni.Notes, Spedizioni.Utente FROM Spedizioni Inner Join Magazzino On Spedizioni.Materiale = Magazzino.ID

Bene, questa query crea una tabella abbinando a ogni record di spedizioni il record in Magazzino con l'id corrispondente, creando direttamente la tabella finale con un massimo di 200 record (basandoci sull'esempio di prima).

Davvero, credimi, stai sprecando tempo, non sapere queste cose significa buttar via ore e ore e ore di lavoro, ma visto che ti ritengo una persona inteligente ti dirò comunque perchè non funziona la tua query, lasciando a te la decisione sulla strada da percorrere, quando tu scrivi "Where Spedizioni.Materiale = Magazzino.ID" gli stai dicendo di confrontare Un campo testo con un campo Contatore, le pere si confrontano con le pere, non con le mele, quindi se proprio vuoi far funzionare questo obrorio devi trasformare uno dei due campi nel formato dell'altro, ad esempio così "Where Spedizioni.Materiale = Cstr(Magazzino.ID)" funziona ma stiamo andando da Roma a Milano passando prima dalla Svizzera poi da Napoli poi da Mosca, poi da Bari quindi da Parigi e quindi finalmente da Milano, davvero non è una cosa inteligente.....





Edit:
Non ci posso credere avete risposto in 3 mentre rispondevo io......... Scusate il triplo CrossPosting, moh ririspondo a TheTruster e a Stegco (Brontolo a te non ho nulla da dire quindi ti saluto e basta )

[sspintux]

...............
La tua query crea una tabella che abbina a ogni record di Spedizioni tutti i record di magazzino ovvero se Spedizioni contiene 200 Record e Magazzino 20 Record abbiamo un totale di 4000 (non quattrocento quattromila) record nella tua tabella poi prende in esame tutti e 4000 i record e esclude tutti quelli per cui non si verifica la codizione Spedizioni.Materiale = Magazzino.ID riducendo i record a un massimo di 200, il che significa che sono stati creati ed elaborati minimo 3800 record inutili.
.........

a dire il vero spike,ed a prescindere dal tipo diverso dei campi, penso proprio che molti dbms la considerino equivalente ad una scritta con la join, che comunque preferisco.

Prova ad eseguirle entrambe con sql server e vedrai che i piani di esecuzione saranno uguali.

[StegcO]

Mea culpa, si in effetti come dice Spike funziona perfettamente

SELECT Spedizioni.ID, Spedizioni.Dat, Spedizioni.A, Magazzino.Materiale, Spedizioni.Quantita, Spedizioni.Stato, Spedizioni.Corriere, Spedizioni.Notes, Spedizioni.Utente
FROM Spedizioni Inner Join Magazzino On Spedizioni.Materiale = CStr(Magazzino.ID)

Scusate se deficito in SQL, oggi ho imparato una cosa in più che onestamente non mi ricordavo fosse così.

Grazie a tutti ma, questa volta, soprattutto a spikexx84, spero di poter ricambiare il favore ù

a dire il vero spike,ed a prescindere dal tipo diverso dei campi, penso proprio che molti dbms la considerino equivalente ad una scritta con la join, che comunque preferisco.

Prova ad eseguirle entrambe con sql server e vedrai che i piani di esecuzione saranno uguali.

Quando a me insegnarono SQL me lo insegnarono facendo la WHERE sui due ID e non facendo INNER JOIN, questo su Access, per quanto può valere il mio parere

[spikexx84]

@Spike: Sinceramente apprezzo il tuo interesse e la tua dedizione nel voler comprendere e chiarificare la richiesta... ma d'altro canto sono convinto che, chi chiede aiuto, lo fa per proprio interesse e, per altrettanto proprio interesse, dovrebbe sforzarsi di rendere chiara la sua richiesta arricchendola di dettagli e scrivendo chiaramente in lingua italiana.

TheTruster

Verissimo, ma io sono un inguaribile ottimista e scrivendo la domanda come andava posta ho cercato di spiegare a Stegco (o ai tanti altri che non sono la quinta essenza della chiarezza) come andrebbero poste le domande, proprio perchè è nell'interesse di chi chiede (e io lo sò, dal momento che non sò se ti ricordi, ma quando sono arrivato qui ero più o meno ai livelli di Stegco), spiegarsi al meglio, mostrare buona volonta e facilitare il più possibile chi ci vuole rispondere e aiutare oltretutto gratuitamente, sempre sulla falsariga di quel che ho detto per mostrare che non predico solo bene, posto una domanda fatta da me sul forum poco tempo fa a cui hanno risposto sia TheTruster che Spintux, prova dacci un occhio Stegco e guarda la differenza fra la mia domanda e la tua

[MshFlexgrid]Proprietà Datasource, prima vuoto poi pieno, selezione sballata

Scusate, ma quindi se io voglio avere una corrispondenza tra due tabelle, come in questo caso, cioè gestire un campo tramite un codice che fa riferimento a una seconda tabella (contente altre informazioni a riguardo) dovrei, nella seconda tabella, NON utilizzare il campo Contatore? e come posso gestire la crezione, per esempio, di un nuovo Record se non ho l'aiuto di un contatore?

Grazie per le info

No non ci siamo, ma certo che i campi id vanno usati (fermo restando che con una Insert si può creare un nuovo record comunque anche senza), Brontolo ha espresso con questa Emotion quello che io ho "provato" descrivendo il primo errore come grave, un campo Id è un intero autoincrementato, quindi metterlo di tipo testo è un bestemia pura in termini come minimo di prestazioni e poi anche e soprattutto di struttura del db.

Quello che tu devi fare NON è smettere di usare gli Id di tipo contatore nelle tabelle, ma usare il giusto tipo per i campi che vengono utilizzati per creare le relazioni!!!!!!!!! E ancora creare le relazioni nel modo giusto non con la virgola e una Were ma con le Join.






Edit:
Ma non è possibile, stavolta avete scritto in 2 mentre io scrivevo la mia risposta 5 crossposting in 2 post, ok ora ririspondo a Stegco e a Spintux

[spikexx84]

a dire il vero spike,ed a prescindere dal tipo diverso dei campi, penso proprio che molti dbms la considerino equivalente ad una scritta con la join, che comunque preferisco.

Prova ad eseguirle entrambe con sql server e vedrai che i piani di esecuzione saranno uguali.

Dici davvero? Per la serie non si smette mai di imparare, ho sempre pensato che dando la Join diretta l'engine fosse più veloce, però è anche vero che se è abbastanza "intelligente" potrebbe accorgersi dell'ecquivlenza delle due forme e "tradurle" nella stessa cosa prima di eseguirle, moh faccio un paio di prove e ti faccio sapere.

Mea culpa, si in effetti come dice Spike funziona perfettamente

codice:
SELECT Spedizioni.ID, Spedizioni.Dat, Spedizioni.A, Magazzino.Materiale, Spedizioni.Quantita, Spedizioni.Stato, Spedizioni.Corriere, Spedizioni.Notes, Spedizioni.Utente
FROM Spedizioni Inner Join Magazzino On Spedizioni.Materiale = CStr(Magazzino.ID)
Scusate se deficito in SQL, oggi ho imparato una cosa in più che onestamente non mi ricordavo fosse così.

Grazie a tutti ma, questa volta, soprattutto a spikexx84, spero di poter ricambiare il favore

Di nulla, ma non ci siamo ancora, a meno che ci sia un qualche arcano motivo che io non sò, mi spieghi per quale masochistico motivo mi dichiari il campo Spedizioni.Magazzino come testo? L'errore principale è li, devi dichiararlo come InteroLungo NON come testo.

Quote:
Originariamente inviata da sspintux
a dire il vero spike,ed a prescindere dal tipo diverso dei campi, penso proprio che molti dbms la considerino equivalente ad una scritta con la join, che comunque preferisco.

Prova ad eseguirle entrambe con sql server e vedrai che i piani di esecuzione saranno uguali.

Quando a me insegnarono SQL me lo insegnarono facendo la WHERE sui due ID e non facendo INNER JOIN, questo su Access, per quanto può valere il mio parere

Al mio di professore sarebbe venuto un infarto per un'affermazione del genere, però può darsi che sia davvero solo questione di "forma" e di "eleganza", se lo dice SSpintux è molto probabile che sia così, ma io sono malfidente di natura e faccio qualche prova

[StegcO]

Ho messo il campo Intero Lungo come consigliatomi, tornando al problema principale ora la MSHFlexGrid, grazie alla gestione dei campi tramite Join e non come facevo io, è ALMENO il doppio più veloce.

Pensavo di riuscire ad arrivare a una velocità pari alla DBGrid ma va benissimo uguale.

Grazie a tutti (in questo caso in particolare a spikexx84)