Newsgroup: it.comp.lang.visual-basic
Titolo: cerco consiglio su gestione giorni/settimane/mesi

mi spiego meglio:
ho una tabella categorie.
su questa tabella devo metterci un campo scadenza.
in base al valore di questo campo, in un altra tabella i dati avranno una data di validità.
-
non voglio preimpostare delle scadenze tipo: 1,2,3 giorni, 1settimana, 1mese, 1anno.
vorrei impostare qualcosa che mi permetta di aggiungere scelte personalizzate tipo:
se il cliente poi vuole aggiungere: 4giorni, oppure 2mesi, come glielo faccio fare?
-
magari con una combo con i valori selezionabili possibili: G,M,A per scegliere il tipo di riferimento del valore e un campo di testo
numerico per impostare la quantità? il tutto verrà poi salvato in una stringa del tipo: A1 (1anno) oppure M2 (2mesi) oppure G10 (10
giorni)
voi che ne pensate?
m'è venuta così ora, ma mi sembra un'ottima soluzione.

 mi spiego meglio:
chiariamo tu non misuri una data...ma un periodo!
che è roba da mangiare? farmaci?
ok....
qual è l'unità base?
giorni immagino!
e non te ne frega se feriali o festivi(non è che se è domenica un salame non
scade!!!)
quindi al cliente fai imputare i giorni di scadenza (su quelli calcolerai la
validità del prodotto no?)
al limite in un combo puoi mettere quelli tipici...ma se ci scrive 35 lo
prende uguale!
2 mesi?
beh se non è scemo 2 mesi son 60 gg
ti basta addirittura un integer!
:-)
bye man!
--
Il Wodkino Nazionale è a : 
www.martek.it
Pagina Vb/Bestiario/Lamer Experience :
http://www.martek.it/go.asp?portamia=2
Quotefix e altro: 
http://www.martek.it/go.asp?portamia=4
Usr: ICLVB Pw: amici

 ti basta addirittura un integer!
mi serve una cosa + precisa:
2 mesi possono essere: 62giorni (lug-ago), 61giorni (ago-set)
il metodo che m'č venuto in mente e che ho scritto nel post precedente mi sembra accettabile.
cmq grazie della risposta.

 2 mesi possono essere: 62giorni (lug-ago), 61giorni (ago-set)
cedi help in linea datediff e dateadd (puoi aggiungere mesi, giorni anni
ecc...)

 ecc...)
questa non la sapevo. grazie.
comunque, non vedo come mi possa essere d'aiuto per la tabella di queste categorie.
quello che mi scrivi mi tornerà sicuramente utile sulla tabella delle scadenze.
comunque io ho optato per salvare una cosa del tipo: 0-1 oppure 2-7
dove il primo numero corrisponde a: 0 = anni ; 1 = mesi ; 2 = giorni - mentre il secondo numero alla quantità desiderata.
diciamo che la funzione che m'hai indicato mi diventa utile da qui in poi.
se non è questo che intendevi:
o non ho capito l'uso che mi consigliavi di farne, o non hai capito tu cosa vorrei fare io.

 indicato mi diventa utile da qui in poi.
No, così facendo ti vai ad incasinare (non potrai sfruttare quelle funzioni
consigliate da Lord, se non con salti mortali)
Io seguirei il consiglio di wodka. Deposita la data origine (produzione) e i
giorni di distanza della scadenza (ovvero di validità).
L'interfaccia per l'operatore falla come vuoi (in anni, mesi, quindicine,
decadi, settimane, etc., anche mista), ma deposita, traducendo, i giorni di
validità.

 validità.
Anzi, sempre traducendo e per "prepararsi" un comodo SQL, io depositerei
(adottando quelle funzioni) la data di scadenza, non i giorni di validità.

 mi spiego meglio:
Egregio amico...
Fai un po come ti pare!
Nel senso che alcune soluzioni son state date facendo affidimanto sul
"nulla"
Nel senso che non ci dici una emerita cippa di quello che vuoi fare!E non
siamo indovini!
Parli di periodi di validità...ma poi parli di mesi...etc etc...
Ti posso dire (perchè non c'è da essere gelosi di nulla)
la mia esperienza.....
Ho dovuto fare un magazzino ad uno che produceva "sgnam sgnam" insaccati!
Su quello ci deve essere data di produzione e data di scadenza
alla data di produzione questi signori non aggiungono 2 mesi!
ma i giorni!
Perchè?
Perchè se scrivono 2 mesi quanti giorni sono? 30+30? 28+30? 31+30?
e se un prodotto scade dopo 60 giorni?
se scrivono 2 mesi potrebbe scadere dopo 61...e se uno si sente male li
fanno un culo come la galleria del san Bernardo!
Quindi....
scindiamo i problemi
Se hai da misurare un periodo devi memorizzare il "tot" di unità di misura
es
DataProd 12/7/03 Scadenza 35 gg e il programma si calcolerà la data di
scadenza da stampare sulle etichette
SE INVECE devi fare uno scadenziario la cosa è più complicata!
Puoi fregartene....ma se ad esempio
PAGAMENTO: r.b. 30 gg Data Fatt.
oppure 30/60/90 r.b Fine mese
 beh qui la cosa è complessa...perchè? Perche se vuoi dare un minimo di
"professionalità" devi calcolare che se capita di sabato o domenica la
scadenza va spostata...e allora qui caso mai un calendario custom ci
starebbe bene...aggiornato a tutte le scadenze e festività!
cmq aper quello parrebbe intuire ti serva il programma non vedo la
difficolta nel memorizzare 2 campi
DATAPROD Data
GGSCAD Long
Non sai a 12/5/03 aggiungere 45 giorni?..è questo il problema?


Wodka40° wrote:
.....che si fa cosě!
Un form
2 textbox 1 label 1 commandButton
Option Explicit
Private Sub Command1_Click()
Text2.Text = CStr(DateAdd("d", CDbl(Me.Text1.Text),
CDate(Me.Label1.Caption)))
End Sub
Private Sub Form_Load()
Me.Label1.Caption = Date
End Sub
scrivi 10 in text1 e schiaccia il pulsante
;-)
N.B.
 premi F1 e consulta l'help su DateAdd guarda un po c'č non solo "d" ma
anche "m" ...e......
Bye man!
p.s.
E' didattica ragazzi! Notate come sono bravo con i cast espliciti!
:-P ROTFL :-)
--
Il Wodkino Nazionale č a : 
www.martek.it


 Wodka40° wrote:
ciao Wodka..
non č che ti sei montato un po la testa? senza offesa :o))
Comunque grazie di quello che hai scritto.
Ho letto appena adesso.
Il problema č:
una gestione iscrizioni:
tizio si iscrive e paga per una settimana, un mese, un giorno, un anno...
quindi ho fatto una tabella a parte (ora ti scrivo da casa dopo un
pomeriggio allucinante, manco ricordo + le tabelle che ho..)
nella tabella voglio tener conto dei varii tipi di abbonamenti.
saranno + o meno sempre gli stessi. chi si fa quello mensile, poi ogni mese
pagherŕ nuovamente quello mensile.
per abbonamento mensile s'intende un abbonamento che va ad esempio da oggi,
18/07 al 17/8.
uff....
devo scappare.
mi spiegherň meglio lunedě.
buon week end.

ecco la struttura attuale:
-tabella iscritti:
1) codbar varchar(8)
2) nome..cognome.. dati varii.. varchar(n)
3) data datetime
4) cate int
-tabella categorie
1) id int identity
2) nome varchar(30)
3) tipo varchar(10)
4) accessi int
--
la relazione sta tra 
categorie.id
 e iscritti.cate
--
nella tabella iscritti non faccio uso dell'id, ma uso varchar(8) che dev'essere ed è univoco.
comunque non ci saranno 2 codici a barre identici, quindi ho ritenuto superfluo un indice diverso da quello. concordate?
parecchio tempo fa avevo aperto una discussione del genere e ne era venuto fuori che in certe situazioni fare così non è errato.