Visualizza post

Questa sezione ti permette di visualizzare tutti i post inviati da questo utente. N.B: puoi vedere solo i post relativi alle aree dove hai l'accesso.


Post - sotema

Pagine: 1 [2] 3 4 ... 32
16
Programmazione / Re:Sviluppo Gestionale Rubinetto Felice
« il: 22 Novembre 2015, 17:20:35 »
Ciao Guanluigi,
ho dato uno sguardo veloce all'elenco voci offerta, ci sono due voci ripetute: Sconto cassa e Sconto incondizionato.
A mio parere mancano  le voci Codice Iva e Iva Riga, inoltre terrei separati Partita Iva e Codice Fiscale poiché possono differire.

17
Programmazione / Re:Sviluppo Gestionale Rubinetto Felice
« il: 22 Novembre 2015, 17:00:39 »
Mi raccomando attieniti all'ultima nomenclatura in cinque punti idcliente, id davanti non più dietro e senza underscore.
 :ciao:
PS: Io comando... ma decide Sotema  ;D

Visto che siamo 3 contro 1 vada per cliente_id, sul resto mi pare siamo tutti d'accordo. Quindi si parte.

18
Programmazione / Re:Sviluppo Gestionale Rubinetto Felice
« il: 21 Novembre 2015, 17:47:48 »
Ciao Sotema,
scusa ma mi scappa da ridere non per quello che scrivi, ci mancherebbe! Ma per la situazione che si è venuta a creare, fino ad ora siamo in quattro che abbiamo detto la nostra sulla nomenclatura  e cane se ce n'è uno che è d'accordo con gli altri.  :rotfl:
E fino a qui tutto normale...
Forse ma non sono sicuro Tornu potrebbe avvicinartisi però ama le abbreviazioni tipo piva al posto di partitaiva (o partita_iva).
Berserker79 vorrebbe tutto maiuscolo PARTITA_IVA, io il CamelCase  PartitaIva e se non ho capito male tu semplicemente partitaiva.
Be insomma altrimenti non saremmo italiani.  :D
Almeno in questo caso siamo d'accordi in due, anch'io come Tornu preferisco abbreviare laddove possibile. Gli esempi che ho postato erano solo...esempi.
Per quanto riguarda il tutto maiuscolo apprezzato da Berserker79, purtroppo come hai già scoperto è PostgrSQL stesso che pone dei vincoli e dover scrivere sempre i nome racchiusi tra doppi apici può portare ad errori, oltre che complicare la vita.
Ripeto se ho capito bene sei d'accordo su abbreviare i nomi solo dove non ci può essere incomprensione se ad esempio Tornu a cui piacciono le abbreviazioni "spinte" ha voglia e tempo può postare un elenco di abbreviazioni per evitarcele (le incomprensioni).
La chiave primaria scritta idcliente a me va bene anche io non ho remore, solo sono molto paciugone e tendo sempre a confondermi è per quello che metto il prefisso per sapere di chi è il campo io quelle poche volte che ho creato query complicate ho sempre usato gli alias non sapevo che il prefisso me le potesse evitare  :rolleyes:
Se e appena avrò tempo preparo un elenco di abbreviazioni anch'io, poi sceglieremo tra tutte le proposte.
Ricapitoliamo:
1. I nomi delle tabelle non contengono spazi e devono sempre essere plurali se un nome di tabella deve riportare un nome composto tipo aliquoteiva lo si rovescerà per ottenere un chiaro finale plurale e cioè ivaaliquote.
2. I nomi di campo devono sempre essere singolari si potranno abbreviare la dove non è possibile fraintenderne il significato non possono contenere spazi né lettere accentate es. citta e non città (è ovvio ma è bene dirlo).
3. Le chiavi primarie inizieranno con id tipo idcliente
4. Le chiavi esterne saranno nominate come le loro chiavi di origine.
5. Per facilitare la lettura delle QUERY le scriveremo su più righe tipo:
    sMioSql = "SELECT *"
    sMioSql &= " FROM clienti"
    sMioSql &= " ORDER BY cognome DESC,"
    sMioSql &= " nome DESC"
    sMioSql &= ";"

Caro Berserker79 io e te ci dobbiamo sacrificare e probabilmente un po anche Tornu ma non possiamo proprio inimicarci Sotema che è l'unico che conosce PostgreSQL.   ;D :P

Scherzi a parte visto che dobbiamo dialogare con lui tanto vale farlo come vuole PostgreSQL.
Ci abitueremo meglio a leggerne le risposte.
 :ciao:

19
Programmazione / Re:Sviluppo Gestionale Rubinetto Felice
« il: 20 Novembre 2015, 22:58:56 »
1. I nomi delle tabelle devono sempre essere plurali se un nome di tabella deve riportare un nome composto tipo aliquote_iva lo si rovescerà per ottenere un chiaro finale plurale e cioè iva_aliquote.
2. I nomi di campo devono sempre essere singolari si potranno abbreviare la dove non è possibile fraintenderne il significato.
3. I nomi di campo saranno preceduti dalle prime tre lettere del nome della tabella più il tratto di sottolineatura fatto salvo il punto 2 e cioè fraintendere a quale tabella ci si riferisce.
Si potrebbe aggiungere che se una tabella è composita il prefisso raddoppierà tipo rig_ord_prezzo.
4. Le chiavi primarie inizieranno con le prime tre lettere del nome della tabella fatto salvo il punto 2 e 3 e finiranno con _id.
5. Le chiavi esterne saranno nominate come le loro chiavi di origine.
6. Più in generale direi che che tutti i nomi escluso i comandi SQL vadano scritti minuscolo e separati dallo underscore o trattino basso.
7. Per facilitare la lettura delle QUERY proporrei di scriverle su più righe tipo (scusate la banalità):
    sMioSql = "SELECT *"
    sMioSql &= " FROM clienti"
    sMioSql &= " ORDER BY cli_cognome DESC,"
    sMioSql &= " cli_nome DESC"
    sMioSql &= ";"
Premesso che non ho remore ad applicare la metodologia indicata queste le mie considerazioni.
1. OK
2. OK
3. Di solito non uso prefissi nel nome di campo, preferisco usare gli alias1
4. Non mi piace usare il trattino basso, rallenta la digitazione, solitamente uso idcliente e non id_cliente.
5. Assolutamente d'accordo
6. Vedi punto 3
7. Se vuoi che la sentenza SQL nel codice sia comprensibile dovrai obbligatoriamente attenerti a questo.

1 Gli alias sono un modo per abbreviare la sentenza SQL. Ad esempio invece di scrivere
Codice: [Seleziona]
SELECT prodotti.descrizione, fornitori.ragionesociale FROM prodotti, frornitori ...;
puoi scrivere:
Codice: [Seleziona]
SELECT p.descrizione, f.ragionesociale FROM prodotti as p, fornitori as f ...;
dove p ed f sono gli alias di tabella. In query molto lunghe sono molto utili, indispensabili quanto due o più nomi di campo nella query sono uguali.

20
Programmazione / Re:Sviluppo Gestionale Rubinetto Felice
« il: 18 Novembre 2015, 21:37:46 »
Ciao Gianluigi,
vedo che ti stai impegnando molto nello studio di PostgreSQL. Bravo.
Ho seguito lo scambio tra te e Berseker79 e devo dire che sono d'accordo con entrambi. Dal punto di vista dello studio fai benissimo ad approfondire la conoscenza di PostgrSQL, un database sofisticato e potente, quindi complicato.
Riguardo l'uso delle chiavi esterne vorrei precisare che il loro scopo principale è quello di garantire che non vengano immessi valori non congrui in un determinato campo; ad esempio nella tabella ordini il valore di cliente_id deve obbligatoriamente esistere nella tabella clienti. in caso contrario PostgreSQL impedirà l'immissione del record. Ma se l'immissione dati viene effettuata tramite un applicativo (non da sql) tale verifica la puoi fare molto semplicemente popolando una combobox con tutti i clienti attivi, rendendo inutile la FK. In alternativa dovresti gestire l'eventuale messaggio di errore, cosa assai più complicata.
Anche riguardo le sequenze, nella progettazione di un gestionale, spesso conviene la soluzione proposta da Berseker79, una tabella contenente l'ultimo progressivo ti semplifica di molto il lavoro; non pensare mai di utilizzare una sequenza, ad esempio, per il progressivo di una fattura. Ad ogni cambio anno dovrai reinizializzare la sequenza, tieni presente che il progressivo della sequenza viene incrementato solo al momento dell'immissione del record.
Rimane il fatto che conoscere la materia che si tratta è fondamentale.

21
Programmazione / Re:Sviluppo Gestionale Rubinetto Felice
« il: 16 Novembre 2015, 22:16:04 »
Scusate ragazzi ma sono due giorni (quasi tre) che mi picchio col sistema operativo (Ubuntu 14.04.3).  :-[
Ho fatto un errore che lo ha reso instabile e alla fine mi sono deciso a reinstallare lasciando però la partizione /home intatta. Il fatto è che prima di decidermi alla reinstallazione le ho provate tutte quelle che so ma anche che non so e infatti ho solo perso tempo.
Ora pare funzionare.
Sbagliando si impara... ;D

@Sotema,
seguendo i tuoi consigli finalmente sono riuscito a creare con SEQUENCE la chiave auto incrementale come desideravo per capire anche il ciclo.
É molto semplice, arrivato all'ultimo numero ricomincia da capo ma attualmente non riesco a immaginarmene un utilizzo pratico.
Lo studio di PostgreSQL continua...  :D
Il valore massimo di una sequenza è pari a 263-1 per le sequenze ascendenti e -1 per le sequenze discendenti; raggiunto tale valore la prossima chiamata a nextval() genera un errore. La soluzione è far ripartire la sequenza. Ovviamente devi gestire la cosa qualora il campo controllato dalla sequenza debba contenere valori unici.

io chiederei a sotema di darci una dritta in quanto è l'unico a usare già PostgreSQL che, se ho capito bene, cambia tutto in minuscolo.
Sotema hai parlato anche di standardizzazione della struttura cosa intendevi esattamente?
La 'traduzione' in minuscolo è una convenzione utilizzata per migliorare la lettura delle query, dove le parole chiave vengono scritte in maiuscolo per distinguerle dai nomi di campi, tabelle, funzioni ed ogni altro oggetto del DB. Esiste comunque la possibilità, che personalmente non utilizzo mai e che sconsiglio vivamente di memorizzare i nomi in maiuscolo, i doppi apici: CREATE TABLE "CLIENTE" ...
Riguardo la standardizzazione dei nomi, ogni strada è valida, purché la si rispetti in tutte le tabelle; circa la struttura ti faccio un esempio pratico.
Nella tabella cliente abbiamo il campo cli_id che diventa relazione per la tabella ordine_cliente, ebbene il campo nella tabella ordine_cliente deve chiamarsi anch'esso cli_id.

Vi rimanderei al primo post quello di apertura di questa discussione, siamo d'accordo sul sentiero da seguire per non perderci o avete proposte più sensate e/o complete da avanzare?
Grazie
 :ciao:
Ora vado a rileggerlo.

22
Programmazione / Re:Sviluppo Gestionale Rubinetto Felice
« il: 14 Novembre 2015, 19:35:08 »
Ciao Sotema,
grande  :ok: spiegazioni dettagliatissime ora mi metto a studiare :ok: :D

Riguardo a COPY a seguire quanto ho tentato di fare, come vedi il database impedisce all'utente di copiare da un file di testo dicendo che non ha i privilegi di superuser anche se poi suggerisce che chiunque può copiare. Nota che test è colui che ha creato il database e può usare select e insert :rolleyes:
Codice: [Seleziona]
gian@gian:~$ psql -U test -d template1
Password for user test:
psql (9.3.10)
Type "help" for help.

template1=> \c mio_test
You are now connected to database "mio_test" as user "test".
mio_test=> \d Articoli
               Table "public.articoli"
     Column      |         Type          | Modifiers
-----------------+-----------------------+-----------
 id_art          | character varying(10) |
 art_descrizione | text                  |
 art_prezzo      | numeric               |

mio_test=> SELECT * FROM articoli;
mio_test=> COPY Articoli
mio_test-> FROM '/home/gian/Articoli.txt'
mio_test-> DELIMITER ';';
ERROR:  must be superuser to COPY to or from a file
HINT:  Anyone can COPY to stdout or from stdin. psql's \copy command also works for anyone.
mio_test=> \du
                             List of roles
 Role name |                   Attributes                   | Member of
-----------+------------------------------------------------+-----------
 giangi    | Create role, Create DB                         | {}
 postgres  | Superuser, Create role, Create DB, Replication | {}
 test      | Create role, Create DB                         | {}
Ma il comando di psql (\copy) può essere usato da Gambas con exec?
 :ciao:

PS: mi scuso col Manzoni per aver confuso un suo personaggio con la spiaggia di Palermo  :-[
Si solo un SUPERUSER può copiare da o verso un file. Un utente normale può usare COPY tabella (campo1,campo2,...) FROM stdin WITH DELIMITER 'carattere_separatore';

23
Programmazione / Re:Sviluppo Gestionale Rubinetto Felice
« il: 14 Novembre 2015, 16:27:53 »
Codice: [Seleziona]
CREATE TABLE mioschema.impiegati(
ID_Imp serial,
imp_codice text,
imp_cognome text,
imp_nome text,
PRIMARY KEY(ID_Imp),
UNIQUE(imp_codice)
);

– vari inserimenti con lo stesso schema devo ancora capire le funzioni di PostgreSQL.
INSERT INTO mioschema.impiegati (imp_codice, imp_cognome, imp_nome) VALUES ('codice6', 'Sergia', 'Mellina');

SELECT nextval('mioschema.impiegati_id_imp_seq');

INSERT INTO mioschema.impiegati (ID_Imp, imp_codice, imp_cognome, imp_nome) VALUES (nextval('mioschema.impiegati_id_imp_seq'), 'codice8', 'Lucia', 'Mondello');

INSERT INTO mioschema.impiegati VALUES (nextval('mioschema.impiegati_id_imp_seq'), 'codice9', 'Lorenzo', 'Tramaglino');

NOTA2: Avendo letto con SELECT il nextval mi si è creato un vuoto.

Nella tabella hai creato il campo ID_Imp specificando come tipo di dato SERIAL, che è uno speciale tipo di INTEGER ad autoincremento. Quando specifichi il tipo SERIAL per un campo PostgreSQL crea automaticamente una sequenza associata ad esso per generare il valore che andrà immesso nel recordo successivo. In effetti le istruzioni:
Codice: [Seleziona]
CREATE TABLE fornitore
(
  fornitore_id serial,
  ...
);

oppure
Codice: [Seleziona]
CREATE SEQUENCE fornitore_id_seq
  INCREMENT 1
  MINVALUE 1
  MAXVALUE 9223372036854775807
  START 1
  CACHE 1;

CREATE TABLE fornitore
(
  fornitore_id integer DEFAULT nextval('fornitore_id_seq'::regclass),
  ...
)

sortiscono lo stesso effetto. Ad ogni inserimento di record nella tabella il campo fornitore_id verrà incrementato di un intero.

Il vantaggio di utilizzare una sequenza personalizzata consiste nel fatto che puoi determinare quale sia il valore dell'incremento.
Codice: [Seleziona]
CREATE SEQUENCE fornitore_id_seq
  INCREMENT 2
  MINVALUE 1
  MAXVALUE 9223372036854775807
  START 1
  CACHE 1;
genera una successione di soli interi dispari.   ;)

L'incremento è inteso in senso algebrico.
Codice: [Seleziona]
CREATE SEQUENCE prova_id_seq
  INCREMENT -1
  MINVALUE 10
  MAXVALUE 1000
  START 1000
  CACHE 1;
genera una squenza decrementale.  ;D

Citazione
NOTA2: Avendo letto con SELECT il nextval mi si è creato un vuoto.
l'istruzione SELECT nextval('nome_sequenza'::regclass) non fa altro che forzare l'incremento della sequenza, non avendo inserito record nella tabella cui questa si riferisce ottieni un 'vuoto'. Esistono alcuni metodi per manipolare le sequenze.
Citazione
DOMANDA: Ho visto che ci sono parecchie funzioni in PostgreSQL immagino che siano più veloci di quanto può fare Gambas ciclando la SQL, come ti regoli di solito?

Penso ti riferisca ai metodi del componente gb.db come Connection.Find, Connection.Edit ... il quale ha lo scopo di creare un livello intermedio tra l'applicazione ed il database. Non sapendo a priori quale DB userai (SQLite, MySQL,PostgreSQL) questi metodi ti sono di notevole aiuto, poichè non dovrai modificare il codice per adattarlo ad eventuali realtà differenti. Sarà Gambas a convertire l'istruzione nella sintassi corretta.
Se diversamente stai scrivendo una applicazione che utilizzerà solo e comunque uno specifico DB, allora con il comando Connection.Exec("istruzione sql") potrai ottenere un maggior controllo al costo di qualche riga di codice (ed eventuali errori) in più.
Libero arbitrio.... 8)

Citazione
Ho visto che per usare COPY, ad esempio molto potente per copiare i dati da un file di testo, occorre avere i privilegi di super user; è possibile cambiare ruolo durante l'utilizzo da parte dell'utente? Oppure c'è un modo per dare questo specifico privilegio ad un user?
Ti riferisci al comando COPY di sql oppure al comando \copy di psql? Ad ogni modo, per utilizzare il comando COPY (FROM/TO) da sql devi possedere il privilegio di SELECT (per COPY TO) sulla tabella da cui vuoi prelevare i dati, il privilegio INSERT per la tabella in cui scrivere i dati (per COPY FROM). In realtà ti basta avere quei privilegi per le colonne che utilizzi nel comando.
Chiaro?
Infine NO il privilegio di SUPERUSER non può ssere cambiato al volo. Puoi assegnarlo nella fase di creazione dell'utente o utilizzare in seguito l'istruzione
Codice: [Seleziona]
ALTER ROLE nomeutente WITH SUPERUSER;


24
Programmazione / Re:Sviluppo Gestionale Rubinetto Felice
« il: 11 Novembre 2015, 23:55:56 »
Ciao Gianluigi purtroppo in questi giorni non ho possibilità di usare internet e sto scrivendo dal cellulare. Nel fine settimana ti chiarirò i dubbi.

25
Programmazione / Re:Sviluppo Gestionale Rubinetto Felice
« il: 09 Novembre 2015, 20:53:56 »
Sai mi sto rendendo conto di che bestia è PostgresSQL rispetto ai giocattoli da me usati fino ad ora ho dato il comando template1=> \h ALTER e... mi sono spaventato del risultato.
Veramente straordinario quello che può fare questo database, più ne leggo e più mi accorgo di quel niente che so e pensare che ho solo iniziato e che una buona parte di quello che ho letto non l'ho neanche capita...  :rolleyes:

È interessantissimo e continuo a “picchiarmi” con lui il divertimento, almeno il mio, prosegue...  :D
 :ciao:

Hai dato un'occhiata al link che ti ho segnalato? Contienela documentazione, versione 9.1, quasi completamente tradotta in italiano.
 :ok:

26
Programmazione / Re:Sviluppo Gestionale Rubinetto Felice
« il: 08 Novembre 2015, 21:13:20 »
Bravo Gianluigi, vedo che ti stai impegnando.  ;D
L'impegno ce lo metto, purtroppo il cervello è quello che è  :mad:

Citazione
Mai successo.
dovrei vedere il codice...

Ho creato l'utente come da tue istruzioni salvo cambiare test in giangi e la password.
(Mi è venuta in mente una cosa la prima volta che ho usato pgAdminIII ho salvato la password ma poi mi sono accorto che quando accedevo al database da terminale con psql -U giangi -d template1 non mi veniva più chiesta la password e allora sono andato di nuovo su pgAdminIII e ho tolto la spunta e adesso è tornato a chiederla. Che sia dovuto a questo?)
 :ciao:
Hai ragione, il file .pgpass viene creato da pgadmin3 se decidi di salvare la password. la cosa mi era sfuggita perchè non utilizzo mai questa funzione.

27
Programmazione / Re:Sviluppo Gestionale Rubinetto Felice
« il: 08 Novembre 2015, 18:47:25 »
Bravo Gianluigi, vedo che ti stai impegnando.  ;D

Precedentemente a FDW era possibile linkare un database SQL Server tramite ODBC driver; la configurazione era più complessa e richiedeva l'installazione del driver odbc come componente aggiuntivo.
Ciao Berserker79,
ti ringrazio molto per le tue dettagliate spiegazioni  :ok:, certo è che più mi parlate di gestionale e più mi rendo conto in che bel ginepraio vi sto attirando  :D
Caro Sotema,
ho scoperto una cosa che mi ha lasciato di stucco: Nella mia home c'è un file (.pgpass) che mostra in chiaro la password dell'utente giangi ma non l'avevamo criptata in md5?  :rolleyes:
Mai successo.

È forse dovuto al fatto che per brevità l'ho inserita direttamente nel codice?
 :ciao:  :ciao:

dovrei vedere il codice...

28
Programmazione / Re:Sviluppo Gestionale Rubinetto Felice
« il: 07 Novembre 2015, 15:47:55 »
Ciao Sotema,
quindi non real ma numeric per precisione decimale sui soldi, grazie.  :ok:
Avevo un po guardato saltabeccando la sontuosa documentazione di PostgreSQL, peccato che sia in inglese che d'accordo che è un pochino più semplice di prima da capire visto il grande aiuto di Google Translator, però quando si affrontano concetti nuovi...  :rolleyes:
http://docs.itpug.org/

Ti chiedo alcune cose, ma sia chiaro che è senza impegno alcuno, intendo dire che se non hai tempo o voglia non mi rispondi e io rimango contento di te in uguale misura, lo giuro davvero.
Già hai spiegato che PostgreSQL può lavorare sia in locale che in rete e la tua guida mi ha permesso di creare un database di prova ecc..., potresti ora delineare un po meglio il quadro:
Dove sono i vari file di PostgreSQL?
se ti riferisci ai vari database la loro locazione è determinata dalla variabile d'ambiente PGDATA, può variare a seconda del SysOp in uso (Linux, Win, BSD...), su linux può variare a seconda della distribuzione , in genere sono nella cartella /var/lib/postgresql/9.4/main/base ma sono identificati da un codice numerico e non è immediato associare un cluster, questo è il termine esatto, al nome del DB.

Come lo/li spedisci a un cliente?
Tra le varie utilità a disposizione vi è l'applicazione pg_dump che esegue il backup di un intero database; dispone di molte opzioni (a te la ghiotta occasione di studiarle). Per effettuare la copia della struttura di un DB vuoto da trasferire al cliente puoi usare la sintassi:
Codice: [Seleziona]
pg_dump -f rubifelix -U test -s -C -d rubinettofelice
che crea un file di testo contenente le istruzione SQL per creare il database. Tale file può essere dato in pasto a pg_restore (non mi chiedere a cosa serve perché ti licenzio  ;D) oppure puoi farlo leggere dal client psql con il comando \i nomefile

Crei il database da codice al momento del primo avvio? Se si o a volte, dove lo inserisci?
In linea di principio preferisco creare una classe specializzata per creare il db, nel caso questi non esista, al primo avvio del programma.

Ora vado a farmi delle caldarroste... :ciao:

29
Programmazione / Re:Evento Mouse_Click non sempre scatenato
« il: 06 Novembre 2015, 16:00:00 »
La WIKI è accessibile anche dalla home page del forum http://www.gambas-it.org/wp/

30
Programmazione / Re:Sviluppo Gestionale Rubinetto Felice
« il: 06 Novembre 2015, 14:15:14 »
Oggi qualche passetto avanti nella comprensione dei database penso di averlo fatto.  :D

Bene.
Una cosa che non ho capito \dn a me mostra solo public e postgres come schema.
Devo pensare lo Schema come un contenitore in cui puoi creare oggetti del db da tenere separati da altri consentendone l'accesso a gruppi di utenti specifici. E' perfettamente lecito avere una tabella Cliente nello schema Public ed una tabella Cliente nello schema Gianluigi.
Per indirizare l'una o l'altra devi usare la sintassi schema.tabella  Public.Cliente o Gianluigi.Cliente. Ovviamnete i dati contenuti nelle due tabelle possonon differire o essere identici.
Lo schema Public è lo schema predefinito (postgres non è una schema ma il proprietario dello schema Public) e viene creato dalla configurazione iniziale.
Per creare un nuovo schema devi itulizzare il comando
Codice: [Seleziona]
CREATE SCHEMA nomeschema ...
Nel file di configurazione postgresql.conf la chiave search_path serve ad impostare la lista degli schemi in cui effettuare la ricerca degli oggetti.
Lo schema da utilizare può essere anche impostata al volo con l'istruzione sql SET SEARC_PATH nome

Un consiglio, per i valori monetari, laddove serve una corretta approssimazione, puoi usare il tipo Numeric, progettato appositamente per contenere valori monetari, tieni presente che le operazioni matematiche su questo tipo sono più lente rispetto agli Integer.

Pagine: 1 [2] 3 4 ... 32