Firebird + Zeos

[Serpente80]

Mica hai qualche esempio da mostrare ? Te ne sarei eternamente grato.

[xinyiman]

Serpente ma tu non vorrai vedere delle combobox all'interno della dbgrid tipo in access?! Cioè che grazie alle relazioni automaticamente ti imposta le combobox e via discorrendo?!

[Stilgar]

xinyiman... in Delphi quando dicevi che un campo era di lookup su di un'altra entità ti ti forniva la combobox ... sospetto che sia quello che sta chiedendo.
Data una DBGrid, impostati i campi di lookup, messi in relazione tra di loro:come mai non esce la combo di conseguenza?
Serpente.
Allora devi creare un campo "virtuale" nella tua DataSet.
Al wizard devi indicare che è un campo di Lookup.
Imposti le info che servono e ottieni il comportamento delle combo nel caso di campi di lookup.
(Visual Studio ... .Net? Se è .Net il papà di questo linguaggio è lo stesso di Delphi ... quindi il 90% delle cose sono simili, magari si ottengono con un giro del fumo diverso da quello in cui sei abituato).

Stilgar

[Serpente80]

No, non parlavo del lookupcombobox.
Riformulo ...
Ho un DB con 3 tabelle: CLIENTI,ARTICOLI e SCHEDE.
La tabella schede deve "unire" gli ARTICOLI di un dato CLIENTE.
Ho questo form:

Posso gestire le 3 tabelle utilizzando una solo query/datasourse o me ne serve una per ogni tabella ?
C'è un modo "automatico" per far capire al DB che a quella SCHEDA deve associare un determinato cliente e tot articoli ?

[Stilgar]

Se mi dai la struttura delle tabelle con le chiavi esterne ti posso aiutare.
Stilgar

[Serpente80]

Ecco:




Se non sono chiare te le rimando.

[Stilgar]

Bene ... nelle alter table hai i campi che devi impostare come chiavi di "match" tra le tabella slave (articoli e cliente) alla master (scheda).
Solo che devi "girare" il rapporto.

Quindi per fare un esempio:
Imposti schede come master della clienti.
Imposti Schede.IDCliente come campo di riferimento da mettere in relazione Cliente.IDDCliente.
Prova e fammi sapere.
Stilgar

[nomorelogic]

c'è qualcosa che non mi convince tra la gui e la definizione delle tabelle

Da quello che vedo, la tabella SCHEDE ha una relazione 1:1 sia con CLIENTI che con ARTICOLI (infatti la PK di SCHEDE è IDSCHEDE).

Nell'immagine del form però c'è una griglia e quando leggo "La tabella schede deve "unire" gli ARTICOLI di un dato CLIENTE" mi viene da pensare che in realtà la relazione tra SCHEDE e ARTICOLI dovrebbe essere 1:N.
In questo caso la PK di SCHEDE dovrebbe essere IDSCHEDE + IDARTICOLO.

Le intenzioni potrebbero anche essere altre ma se si vuole che un IDSCHEDE rappresenti un legame con tutti gli articoli secondo me bisogna aggiungere IDARTICOLO alla PK

[Stilgar]

nomore, schede è la rappresentazione di una relazione n a m con attributi.
Nulla di assurdo
IDScheda è una chiave artificiale e non naturale

[Serpente80]

State parlando arabo 

[Stilgar]

albrulabtasa.  .... forse è più chiaro

Serpente. Allora la questione è semplice.
Vuoi legare una entità (tabella) ad un'altra.
Questo via DDL lo fai con i costrutti di foreign key.
Nel caso di rapporti 1 a N basta una semplice chiave esterna e la questione è terminata.
Nel caso di rapporti N a M devi appoggiarti ad una tabella di legame.
Nel tuo caso la tabella SCHEDE è la tabella di legame.
Questa contiene le chiavi esterne sulle entità di riferimento (CLIENTE E ARTICOLO).

La cosa non è sbagliata e nemmeno senza senso.
Un cliente può comperare più articoli.
Un articolo può essere comperato da più clienti.
A questa relazione intermedia metti altre infomazioni (N a M con attributi).

Stilgar
EDIT PS:
Le speculazioni che facevamo con Nomore sono legate alla chiave e agli indici, per questioni di velocità nelle ricerche e altre amenità che si possono considerare anche in un secondo momento.
Ri-Stilgar

[Serpente80]

Spè, una cosa per volta 
N ed M stanno per ?
Come rendo Master la tabella SCHEDE ?
Cosa dovrei modificare nel DB ?
Ve l'ho detto che non ho mai avuto a che fare seriamente coi DB relazionali 

[nomorelogic]

nomore, schede è la rappresentazione di una relazione n a m con attributi.
Nulla di assurdo
IDScheda è una chiave artificiale e non naturale

nel database l'intenzione sembra quella ma la gui, d'altro canto, mi sembra che nasca con un'altra idea
potrebbe essere se nell'immagine del form, i campi DATA e CLIENTE, quelli fuori dalla griglia in realtà non sono campi ma semplici TEdit da usare come filtri di ricerca per farci una select

poi una relazione N:M non dovrebbe permettere l'esistenza di situazioni ambigue tipo

Scheda	Cliente	Articolo	Data	Note
1	758	GOLF	01/01/2013	nota 1
2	758	GOLF	01/01/2013	nota 2
3	758	GOLF	01/01/2013	nota 1

ok, è illogico caricare come sopra, ma è possibile, quindi: se vengono caricati record così, cosa ci si fa?

@Serpente
scusa la curiosità, ma cosa dovresti rappresentare con la tabella SCHEDE?

[nomorelogic]

Spè, una cosa per volta 
N ed M stanno per ?
Come rendo Master la tabella SCHEDE ?
Cosa dovrei modificare nel DB ?
Ve l'ho detto che non ho mai avuto a che fare seriamente coi DB relazionali 

anche tu una cosa per volta
come dicevo nell'altro post, scpiegaci meglio cosa vuoi fare con SCHEDE

[Serpente80]

Come dicevo,
Il form SCHEDA deve contenere la data dell'ordine, le note, i dati del cliente e gli articoli nella dbgrid.
Ma non date troppo retta alla struttura del mio DB, che potrei aver cannato totalmente.