Newsgroup: it.comp.appl.access
Titolo: Valore DMax

Ciao a tutti,
dovrei impostare un campo il quale una volta visualizzato in una finestra mi
suggerisca il valore del numero più alto di tutti i record di quel campo.
Il nome della Tabella è: Ordini
Il nome del Campo è: NumeroOrdine
Il nome della Maschera è: Ordini
Mi è stato suggerito di utilizzare la funzione DMax ma non ci sono riuscito.
Io ho provato a inserire tra la proprietà "Valore predefinito" del campo
NumeroOrdine contenuto nella maschera "Ordini"
la seguente espressione:
=DMax([Ordini];"NumeroOrdine")
ma non funziona in quanto nella finestra appare la scritta "?NOME"
Mi sapete dire dove sbaglio, tenendo conto che non voglio utilizzare i
contatori.
Ringrazio tutti in anticipo
Ciao da Emiliano

 wrote in message
Quim8.50056$%g7.15...@twister2.libero.it...

Non hai letto bene l'help su Dmax (l'hai letto vero?)
Tutti i parametri sono stringhe (o variabili che contengono stringhe) ergo,
sarà
dmax("Ordini","NumeroOrdine")
Antonio
P.S.
Aspè, però pensandoci bene sembra anche che tu abbia scambiato i parametri:
prima ci va il nome del campo, poi il nome della tabella


Mancano le virgolette e poi prima va il campo e poi la tabella.
=DMax("NumeroOrdine";"[Ordini]")
p.s. un consiglio: se qualcuno ti suggerisce l'uso della DMax perche' non
premere F1, cercare DMax ed avere la sintassi corretta ed il relativo
esempio di utilizzo. Senza offesa.
Ciao
--
Andrea

Ciao Antonio,
ti ringrazio per la risposta che mi è stata di grande aiuto per altre cose,
ma adesso sto cercando un'altra cosa, mi rendo conto di non essermi spiegato
bene.
L'espressione che mi hai indicato mi da il valore massimo di tutti i record
ma io vorrei che mi dasse l'ultimo valore di una sequenza di numeri
progressivi o meglio se nei record ci sono i seguenti numeri:
1,2,3,4,5,7,9,10,11,12,13,14
io vorrei che mi dasse il numero 7 o il numero 8 che è quello che manca per
completare la progressività dei numeri.
Si può fare?
Ringrazio in anticipo.
Ciao da Emiliano


ti eri spiegato male
per come la vuoi tu dovresti aprire l'archivio ordinandolo per numero
e scorrerlo un record alla volta unitamente ad un contatore per
trovare il primo buco
Saluti.
Emanuele.

 wrote in message
gEjm8.50357$%g7.15...@twister2.libero.it...

Emiliano, perchè vuoi fare ciò?
Non mi dire che stiamo ricadendo sul solito discorso del contatore che non
serve per contare ma per identificare univocamente, vero?
Se c'è un buco, che ti frega!!!
Antonio

 ha scritto nel messaggio
news:Lyum8.56064$1S3.1...@twister1.libero.it...


 Ciao da Emiliano
Be', i trigger after Insert a questo servono. Ovvio che allora devi 
avere un database serio.
Ciao.
Mimmo.

 Antonio
Beh, innanzitutto alcune volte i "BUCHI" servono...!
Scherzi a parte puň capitare di voler riempire la
progressione per evitare codici di MAGAZZINO che si
allungano troppo.
In alcuni casi č una scelta...!!
Questo non sň...!
Alessandro.
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 wrote in message
news:3C9B8C9...@zumzumzum.tin.it...

Caro Mimmo e se il suo "PRESUNTO" Cliente disdice l'ordine
2 settimane dopo, tu che fai...?? Lasci il DB in attesa di conferma???
Io ho dovuto affrontare un problema simile, ma postarti il Codice
è complesso, ti riassumo come ho fatto:
Function Buco() as Integer
Dim rs as Recordset
Dim x,nR As integer
Dim strSQL as String
strSQL="Select Left("[CodiceFattura]",n) as Progressivo Form TuaTabella"
Set rs=CurrentDb.Openrecordset("StrSQL")
If rs.Bof And rs.Eof then 
  Progressivo=1
  Exit Sub
End if
rs.Movelast
nR=rs.RecordCount  
rs.MoveFirst
x=1
Do Until rs.Eof
  If x<Rs.Fields("Progressivo") then
     Buco=x:Exit Function
  End if
  Rs.MoveNext 
  x=x+1
Loop
Buco=x-1
End Function
Circa dovrebbe andare.....!!!
P.S. l'unica cosa che non ho inserito è la FORMATTAZIONE
del Progressivo in base al numero delle cifre, in quanto
presumo sia ovviamente campo TESTO da convertire in Integer....!!!


 2 settimane dopo, tu che fai...?? Lasci il DB in attesa di conferma???
Un ordine annullato è un ordine. E' nel particolare stato di "annullato" 
  per cui non si dà seguito. Non è possibile fare prelievi da magazzino 
per quell'ordine, ad esempio, non c'è produzione per quell'ordine , ecc.
Anche perchè puo` servire per decidere a quali clienti dare la priorità 
(quelli che non cambiano mai idea) o determinare perchè la cambiano spesso.
Di solito non serve a nulla (se non a tappare un buco) ma è 
un'informazione che va tenuta. Insomma, io non lo vedo un problema; poi 
è questione di filosofia dell'utente per cui devi fare i programmi.
IMHO grande come una casa.
Ciao.
Mimmo.

 cancellare i record.
Guarda che mi sembra sbagliato il modo di approcciare. Quando vai in fattura
ormai deve essere tutto certo, altrimenti lo metti in una tabella sospesi, e
solo quando č ok ,lo passi nelle fatture con la numerazione giusta!!!
Antonio


Ok e se poi sbaglio qualcosa e mi rimane il buco che faccio...?
Ciao da Emiliano
P.S. A me sembra molto più pratico sia per chi legge che per chi scrive
scrivere prima del quoting..

 Ok e se poi sbaglio qualcosa e mi rimane il buco che faccio...?
mi sa anche a me che fai un errore nella struttura della cosa.
Cosa vuol dire "se resta un buco"?
Le fatture si sbagliano, capita, e poi si fanno gli accrediti, se vuoi fare
una fattura devi seguire quello che stabilisce la legge, se vuoi farti delle
notine tue, puoi fare quello che vuoi.
Se stai trasformando degli ordini in bolle e delle bolle in fatture, hai
solo due strade, una e' quella di travasare i dati da una tabella all'altra,
e quindi di avere una tabella (o piu') per ogni tipo di documento.
Al momento in cui trasformi la bolla in fattura copi fisicamente il record
da una tabella all'altra.
L'altra e' quella di avere una tabella con tutti i tuoi record, un
identificativo univoco per record e piu' tabelle esterne (volendo anche una
sola)  che contengono i protocolli che associano di volta in volta il record
al documento.
Ho visto usare questa seconda strada diverse volte, a me non piace perche'
obbliga ad avere un tracciato record piu' lungo, se poi in sede di
fatturazione si fanno delle modifiche, il prezzo per esempio, perdi il
"percorso" di quel campo, ovvero non vedi che l'ordine aveva un prezzo e la
vendita un altro.

 vendita un altro.
D'accordo al 100%...
Oooops. Solo ora mi accorgo che č un xpost.
Bč, scusate...
Ciao.
Mimmo.

 scrivere prima del quoting..
ASSOLUTAMENTE NO!
Il flusso logico del discorso va SEMPRE dall'alto verso il basso. Se vuoi
continuare a interscambiare con me attieniti a questa regola!!!
Antonio

 buco.
Come ho gia' detto, se stai facendo qualche pasticcio per comodita' tua,
puoi fare quello che vuoi.
Se stai facendo delle fatture devi rispettare la progressione temporale e
non puoi non registrare delle fatture emesse.
Se invece stai facendo un documento interno, che trasformi in fattura quando
ti serve, con la data e la numerazione nell'ordine giusto, beh, allora non
chiamarla bolla, se non ti va, ma il principio e' quello.
Solo per intendersi sui nomi.

Non è qestione di pasticci o prove, ma mi è più pratico inserire i dati
subito appena qualcuno mi chiede un preventivo, anche per ricordarmi di
fargli il preventivo, non vorrei mai dimenticarmene perchè non l'ho scritto
da nessuna parte!
Inoltre può sempre capitare di fare un'errore, confermare tutto stampare la
fattura e prima di psedirla all'interessato scorprire che c'è un errore!
Inoltre io non ho mai parlato di bolla ma solo di fattura.
Ciao da Emiliano


 ha scritto nel messaggio
news:Quim8.50056$%g7.15...@twister2.libero.it...


 da nessuna parte!
Ok, quindi fai un preventivo e poi trasformi (eventualmente) questo in una
fattura.
E' piu' o meno quello che si diceva, sostituisci la parola "bolla" con
"preventivo" e il tutto torna.
Io preferirei non cancellarli i preventivi e tenerli archiviati e trasformi
in fatture quelli che lo diventano, cosi' risolvi i problemi di protocollo
progressivo e le "cancellazioni", anzi, e' proprio l'idea di cancellare che
non mi piace...
;-)