[Gfoss] PyQGIS

+1 per "layer_name_you_like" anche per i Raster!

Saluti!

----Messaggio originale----
Da: sigfrido@tiscali.it
Data: 05/03/2012 15.46
A: "Salvatore Larosa"<S_Larosa@libero.it>
Cc: <afalciano@yahoo.it>, <gfoss@lists.gfoss.it>
Ogg: Re: [Gfoss] PyQGIS

A questo punto negli esempi del cookbook sarebbe forse meglio restare su
"layer_name_you_like" anche per i raster invece di utilizzare
basename():

iface.addRasterLayer(fileName, "nome del layer nella toc")

Inoltre il sempre ottimo QGIS aggiunge il nome di default (basename())
se non glelo passiamo noi:

iface.addRasterLayer(fileName)

sortisce il medesimo risultato.

Sig

Il giorno lun, 05/03/2012 alle 14.52 +0100, Salvatore Larosa ha scritto:

Nel contesto del Cookbook "baseName" rappresenta il nome del layer
che apparirà nella TOC una volta caricato in QGIS!

Saluti!

>----Messaggio originale----
>Da: afalciano@yahoo.it
>Data: 05/03/2012 14.12
>A: "Luca Sigfrido Percich"<sigfrido@tiscali.it>
>Cc: <gfoss@lists.gfoss.it>
>Ogg: Re: [Gfoss] PyQGIS
>
>Il 05/03/2012 13.51, Luca Sigfrido Percich ha scritto:
>> Ciao,
>>
>> occhio QFileInfo.baseName() restituisce il nome del file senza
>> estensione. [1]
>>
>> "Per caricare un raster, specificarne il percorso completo e il nome
>> privo di estensione" ?
>>
>> Sig
>>
>> [1] http://qt-project.org/doc/qt-4.8/qfileinfo.html#baseName
>
>Grazie per la precisazione. Mi ero limitato al significato di basename
>in Python, mentre nel contesto evidentemente ha un significato diverso.
>
>ciao
>Antonio
>
>--
>Antonio Falciano
>http://www.linkedin.com/in/antoniofalciano
>_______________________________________________
>Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
>Gfoss@lists.gfoss.it
>http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
>Questa e' una lista di discussione pubblica aperta a tutti.
>Non inviate messaggi commerciali.
>I messaggi di questa lista non rispecchiano necessariamente
>le posizioni dell'Associazione GFOSS.it.
>569 iscritti al 4.1.2012

_____________
PRIVACY
Le informazioni contenute in questo messaggio sono riservate e confidenziali.

Il loro utilizzo e' consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora Lei non fosse la persona
a cui il presente messaggio è destinato, La invitiamo ad eliminarlo dal Suo
Sistema e a distruggere le varie copie o stampe, dandone gentilmente
comunicazione all’indirizzo mail del mittente. Ogni utilizzo improprio e'
contrario ai principi del D.lgs 196/03 e alla legislazione europea (Direttiva
2002/58/CE).

PRIVACY
Le informazioni contenute in questo messaggio sono riservate e confidenziali.

Il loro utilizzo e' consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora Lei non fosse la persona
a cui il presente messaggio è destinato, La invitiamo ad eliminarlo dal Suo
Sistema e a distruggere le varie copie o stampe, dandone gentilmente
comunicazione all’indirizzo mail del mittente. Ogni utilizzo improprio e'
contrario ai principi del D.lgs 196/03 e alla legislazione europea (Direttiva
2002/58/CE).

ok..grazie a tutti.

Il 05 marzo 2012 16:08, Salvatore Larosa <S_Larosa@libero.it> ha scritto:

+1 per "layer_name_you_like" anche per i Raster!

Saluti!

----Messaggio originale----
Da: sigfrido@tiscali.it
Data: 05/03/2012 15.46
A: "Salvatore Larosa"<S_Larosa@libero.it>
Cc: <afalciano@yahoo.it>, <gfoss@lists.gfoss.it>
Ogg: Re: [Gfoss] PyQGIS

A questo punto negli esempi del cookbook sarebbe forse meglio restare su
"layer_name_you_like" anche per i raster invece di utilizzare
basename():

iface.addRasterLayer(fileName, "nome del layer nella toc")

Inoltre il sempre ottimo QGIS aggiunge il nome di default (basename())
se non glelo passiamo noi:

iface.addRasterLayer(fileName)

sortisce il medesimo risultato.

Sig

Il giorno lun, 05/03/2012 alle 14.52 +0100, Salvatore Larosa ha scritto:

Nel contesto del Cookbook "baseName" rappresenta il nome del layer
che apparirà nella TOC una volta caricato in QGIS!

Saluti!

>----Messaggio originale----
>Da: afalciano@yahoo.it
>Data: 05/03/2012 14.12
>A: "Luca Sigfrido Percich"<sigfrido@tiscali.it>
>Cc: <gfoss@lists.gfoss.it>
>Ogg: Re: [Gfoss] PyQGIS
>
>Il 05/03/2012 13.51, Luca Sigfrido Percich ha scritto:
>> Ciao,
>>
>> occhio QFileInfo.baseName() restituisce il nome del file senza
>> estensione. [1]
>>
>> "Per caricare un raster, specificarne il percorso completo e il nome
>> privo di estensione" ?
>>
>> Sig
>>
>> [1] http://qt-project.org/doc/qt-4.8/qfileinfo.html#baseName
>
>Grazie per la precisazione. Mi ero limitato al significato di basename
>in Python, mentre nel contesto evidentemente ha un significato diverso.
>
>ciao
>Antonio
>
>--
>Antonio Falciano
>http://www.linkedin.com/in/antoniofalciano
>_______________________________________________
>Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
>Gfoss@lists.gfoss.it
>http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
>Questa e' una lista di discussione pubblica aperta a tutti.
>Non inviate messaggi commerciali.
>I messaggi di questa lista non rispecchiano necessariamente
>le posizioni dell'Associazione GFOSS.it.
>569 iscritti al 4.1.2012

_____________
PRIVACY
Le informazioni contenute in questo messaggio sono riservate e confidenziali.

Il loro utilizzo e' consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora Lei non fosse la persona
a cui il presente messaggio è destinato, La invitiamo ad eliminarlo dal Suo
Sistema e a distruggere le varie copie o stampe, dandone gentilmente
comunicazione all’indirizzo mail del mittente. Ogni utilizzo improprio e'
contrario ai principi del D.lgs 196/03 e alla legislazione europea (Direttiva
2002/58/CE).

PRIVACY
Le informazioni contenute in questo messaggio sono riservate e confidenziali.

Il loro utilizzo e' consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora Lei non fosse la persona
a cui il presente messaggio è destinato, La invitiamo ad eliminarlo dal Suo
Sistema e a distruggere le varie copie o stampe, dandone gentilmente
comunicazione all’indirizzo mail del mittente. Ogni utilizzo improprio e'
contrario ai principi del D.lgs 196/03 e alla legislazione europea (Direttiva
2002/58/CE).

_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
569 iscritti al 4.1.2012

--
Pasquale Di Donato
web: www.padido.eu
chat: padido@jabber.org

Ancora un piccolo aiuto.

Qui: http://qgis.org/pyqgis-cookbook/expressions.html
al terzo punto del primo elenco puntato c’è scritto:

“The names are not escaped.”

Che significa e come posso tradurre?

grazie

Il giorno 05 marzo 2012 17:55, Pasquale Di Donato <pasquale.didonato@gmail.com> ha scritto:

ok…grazie a tutti.

Il 05 marzo 2012 16:08, Salvatore Larosa <S_Larosa@libero.it> ha scritto:

+1 per “layer_name_you_like” anche per i Raster!

Saluti!

----Messaggio originale----
Da: sigfrido@tiscali.it
Data: 05/03/2012 15.46
A: “Salvatore Larosa”<S_Larosa@libero.it>
Cc: <afalciano@yahoo.it>, <gfoss@lists.gfoss.it>
Ogg: Re: [Gfoss] PyQGIS

A questo punto negli esempi del cookbook sarebbe forse meglio restare su
“layer_name_you_like” anche per i raster invece di utilizzare
basename():

iface.addRasterLayer(fileName, “nome del layer nella toc”)

Inoltre il sempre ottimo QGIS aggiunge il nome di default (basename())
se non glelo passiamo noi:

iface.addRasterLayer(fileName)

sortisce il medesimo risultato.

Sig

Il giorno lun, 05/03/2012 alle 14.52 +0100, Salvatore Larosa ha scritto:

Nel contesto del Cookbook “baseName” rappresenta il nome del layer
che apparirà nella TOC una volta caricato in QGIS!

Saluti!

----Messaggio originale----
Da: afalciano@yahoo.it
Data: 05/03/2012 14.12
A: “Luca Sigfrido Percich”<sigfrido@tiscali.it>
Cc: <gfoss@lists.gfoss.it>
Ogg: Re: [Gfoss] PyQGIS

Il 05/03/2012 13.51, Luca Sigfrido Percich ha scritto:

Ciao,

occhio QFileInfo.baseName() restituisce il nome del file senza
estensione. [1]

“Per caricare un raster, specificarne il percorso completo e il nome
privo di estensione” ?

Sig

[1] http://qt-project.org/doc/qt-4.8/qfileinfo.html#baseName

Grazie per la precisazione. Mi ero limitato al significato di basename
in Python, mentre nel contesto evidentemente ha un significato diverso.

ciao
Antonio


Antonio Falciano
http://www.linkedin.com/in/antoniofalciano


Iscriviti all’associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e’ una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell’Associazione GFOSS.it.
569 iscritti al 4.1.2012


PRIVACY
Le informazioni contenute in questo messaggio sono riservate e confidenziali.
Il loro utilizzo e’ consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora Lei non fosse la persona
a cui il presente messaggio è destinato, La invitiamo ad eliminarlo dal Suo
Sistema e a distruggere le varie copie o stampe, dandone gentilmente
comunicazione all’indirizzo mail del mittente. Ogni utilizzo improprio e’
contrario ai principi del D.lgs 196/03 e alla legislazione europea (Direttiva
2002/58/CE).

PRIVACY
Le informazioni contenute in questo messaggio sono riservate e confidenziali.
Il loro utilizzo e’ consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora Lei non fosse la persona
a cui il presente messaggio è destinato, La invitiamo ad eliminarlo dal Suo
Sistema e a distruggere le varie copie o stampe, dandone gentilmente
comunicazione all’indirizzo mail del mittente. Ogni utilizzo improprio e’
contrario ai principi del D.lgs 196/03 e alla legislazione europea (Direttiva
2002/58/CE).


Iscriviti all’associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e’ una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell’Associazione GFOSS.it.
569 iscritti al 4.1.2012


Pasquale Di Donato
web: www.padido.eu
chat: padido@jabber.org


Pasquale Di Donato
web: www.padido.eu
chat: padido@jabber.org

Il giorno gio, 08/03/2012 alle 18.11 +0100, Pasquale Di Donato ha
scritto:

Ancora un piccolo aiuto.

Qui: http://qgis.org/pyqgis-cookbook/expressions.html
al terzo punto del primo elenco puntato c'è scritto:

"The names are not escaped."

Che significa e come posso tradurre?

Si tratta dei caratteri "escape" utilizzati anche nel linguaggio
SQL per evitare errori di esecuzione nelle query!

Per esempio:
SELECT * FROM table WHERE prov = 'L'Aquila'

la query ritorna un errore. Mentre se utilizziamo un "\" prima
dell'apostrofo diciamo a SQL di trattarlo come tale!

Il giorno gio, 08/03/2012 alle 18.11 +0100, Pasquale Di Donato ha
scritto:

Ancora un piccolo aiuto.

Qui: http://qgis.org/pyqgis-cookbook/expressions.html
al terzo punto del primo elenco puntato c'è scritto:

"The names are not escaped."

Che significa e come posso tradurre?

Scusa/te ma mi è partita la mail da sola (si...ho questo privilegio!!.-)
altro crontab)

Cerco di riprendere il discorso (rif. mail precedente):

la seguente query è giusta:

SELECT * FROM table WHERE prov = 'L\'Aquila'

Un'altra soluzione potrebbe essere quella di aggiungere un "e"
all'inizio del nome del valore:

SELECT * FROM table WHERE prov = e'L'Aquila'

Quindi "The names are not escaped." sta ad avvisare lo sviluppatore
che, nel caso vengono utilizzati nomi per i campi che portano ad
ambiguità (per esempio "END" et al) SQL si strozza!

Spero, sopo tutte queste peripezie di essermi spiegato!

Saluti

On Thu, 08 Mar 2012 19:01:43 +0100, Salvatore Larosa wrote:

Il giorno gio, 08/03/2012 alle 18.11 +0100, Pasquale Di Donato ha

"The names are not escaped."

la seguente query è giusta:

SELECT * FROM table WHERE prov = 'L\'Aquila'

Un'altra soluzione potrebbe essere quella di aggiungere un "e"
all'inizio del nome del valore:

SELECT * FROM table WHERE prov = e'L'Aquila'

Quindi "The names are not escaped." sta ad avvisare lo sviluppatore
che, nel caso vengono utilizzati nomi per i campi che portano ad
ambiguità (per esempio "END" et al) SQL si strozza!

veramente, in termini strettamente SQL non mi torna troppo:
ignoro se poi Python ci mette "del valore aggiunto" tutto di suo :wink:

la regola SQL "dura e pura" dice che i text-literal devono essere
recchiusi tra apici ('): p.es.
WHERE prov = 'Pescara'

se il text-literal contiene a sua volta il carattere apice ('),
allora quest'ultimo va ripetuto per due volte consecutive: p.es.
WHERE prov = 'L''Aquila'

ciao Sandro

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Si ho capito… ma come traduco?
Voi siete sicuramente più “sviluppisti” di me…come lo traducete?

gr…

Il giorno 08 marzo 2012 19:25, <a.furieri@lqt.it> ha scritto:

On Thu, 08 Mar 2012 19:01:43 +0100, Salvatore Larosa wrote:

Il giorno gio, 08/03/2012 alle 18.11 +0100, Pasquale Di Donato ha

“The names are not escaped.”

la seguente query è giusta:

SELECT * FROM table WHERE prov = ‘L'Aquila’

Un’altra soluzione potrebbe essere quella di aggiungere un “e”
all’inizio del nome del valore:

SELECT * FROM table WHERE prov = e’L’Aquila’

Quindi “The names are not escaped.” sta ad avvisare lo sviluppatore
che, nel caso vengono utilizzati nomi per i campi che portano ad
ambiguità (per esempio “END” et al) SQL si strozza!

veramente, in termini strettamente SQL non mi torna troppo:
ignoro se poi Python ci mette “del valore aggiunto” tutto di suo :wink:

la regola SQL “dura e pura” dice che i text-literal devono essere
recchiusi tra apici ('): p.es.
WHERE prov = ‘Pescara’

se il text-literal contiene a sua volta il carattere apice ('),
allora quest’ultimo va ripetuto per due volte consecutive: p.es.

WHERE prov = ‘L’‘Aquila’

ciao Sandro


This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


Iscriviti all’associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e’ una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell’Associazione GFOSS.it.
569 iscritti al 4.1.2012


Pasquale Di Donato
web: www.padido.eu
chat: padido@jabber.org

On Thu, 8 Mar 2012 20:32:30 +0100, Pasquale Di Donato wrote:

Si ho capito... ma come traduco?
Voi siete sicuramente più "sviluppisti" di me...come lo traducete?

in genere "noi sviluppisti" continuiamo a chiamarlo "quoting/escaping"
anche in italiano, perche' cosi' ci intendiamo meglio e con minori
ambiguita' :smiley:

se proprio ti scappa di tradurlo, direi a mio gusto personale che
"mascheratura degli apici" potrebbe essere ragionevole.

ciao Sandro

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Precisazione egregia per Sandro, che ringrazio, e confusione estrema per me!

In sostanza ho dato come vero la seguente espressione:
PHP == SQL!!!!(strlen("PHP") == strlen("SQL"), così è verificata però!!)
oggi è stata una giornataccia, mio figlio ha esagerato con il
cambio pannolino! :slight_smile:

Ritornando a PDD, al momento non mi sovviene nulla di risolutivo,
io ti posso aiutare dandoti qualche indicazione (magari un altro
giorno :-o), dicendoti che nel contesto di una query SQL, anche
integrata in codice python, se vengono utilizzate dei testi che inducono
a confusione del codice non vengono risolti automaticamente!

L'esempio della query l'ho fatto perchè nel caso specifico del Cookbook
il riferimento è alla sintassi SQL.
Per esempio se dovessi creare una tabella, eseguo la seguente stringa;

CREATE TABLE (id serial, nome text);

la tabella avrà due campi [id] e [nome]. Se modifichi il campo [nome] e
lo rinomini in [end] la query non viene eseguita perchè END è una
cosiddetta reserved word per il linguaggio SQL!

COmunque, nell'eventualità mi venisse in mente qualcosa ti faccio sapere
tempestivamente e grazie per quello che stai facendo perchè presuppongo
che lo metterai a disposizione della comunità, vero?

Saluti

Il giorno gio, 08/03/2012 alle 20.32 +0100, Pasquale Di Donato ha
scritto:

Si ho capito... ma come traduco?
Voi siete sicuramente più "sviluppisti" di me...come lo traducete?

gr...

Il giorno 08 marzo 2012 19:25, <a.furieri@lqt.it> ha scritto:
        On Thu, 08 Mar 2012 19:01:43 +0100, Salvatore Larosa wrote:
        
                Il giorno gio, 08/03/2012 alle 18.11 +0100, Pasquale
                Di Donato ha
                
                        "The names are not escaped."
                la seguente query è giusta:
                
                SELECT * FROM table WHERE prov = 'L\'Aquila'
                
                Un'altra soluzione potrebbe essere quella di
                aggiungere un "e"
                all'inizio del nome del valore:
                
                SELECT * FROM table WHERE prov = e'L'Aquila'
                
                Quindi "The names are not escaped." sta ad avvisare lo
                sviluppatore
                che, nel caso vengono utilizzati nomi per i campi che
                portano ad
                ambiguità (per esempio "END" et al) SQL si strozza!
                
        veramente, in termini strettamente SQL non mi torna troppo:
        ignoro se poi Python ci mette "del valore aggiunto" tutto di
        suo :wink:
        
        la regola SQL "dura e pura" dice che i text-literal devono
        essere
        recchiusi tra apici ('): p.es.
        WHERE prov = 'Pescara'
        
        se il text-literal contiene a sua volta il carattere apice
        ('),
        allora quest'ultimo va ripetuto per due volte consecutive:
        p.es.
        
        WHERE prov = 'L''Aquila'
        
        ciao Sandro
        
        _______________________________________________
        Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
        Gfoss@lists.gfoss.it
        http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
        Questa e' una lista di discussione pubblica aperta a tutti.
        Non inviate messaggi commerciali.
        I messaggi di questa lista non rispecchiano necessariamente
        le posizioni dell'Associazione GFOSS.it.
        569 iscritti al 4.1.2012

COmunque, nell’eventualità mi venisse in mente qualcosa ti faccio sapere
tempestivamente e grazie per quello che stai facendo perchè presuppongo
che lo metterai a disposizione della comunità, vero?

In effetti pensavo crearci un brevetto… :slight_smile:

Appena pronto lo metto in linea…così mi date una mano a controllarlo…

ciao e a presto

On Thu, 08 Mar 2012 21:21:38 +0100, Salvatore Larosa wrote:

CREATE TABLE (id serial, nome text);

la tabella avrà due campi [id] e [nome]. Se modifichi il campo [nome] e
lo rinomini in [end] la query non viene eseguita perchè END è una
cosiddetta reserved word per il linguaggio SQL!

Niet !!!
puoi usare tutte le parole riservate che credi ...
pero' le devi "infiocchettare" nel modo standad specificato dalla
sintassi universale di SQL.
N.B.: "universale", vale per sqlite, postgres, M$ access etc etc

e qua scatta un altro tipo di quoting: quello con "doppio apice",
ossia "virgolette".
qualsiasi parola racchiusa tra doppi apici non e' piu' un nome
riservato SQL, ma diventa un banalissimo nome definito dall'utente.

provare per credere:

CREATE TABLE "insert" (
   "select" INTEGER PRIMARY KEY,
   "where" DOUBLE,
   "from" TEXT,
   "join" TEXT);

vedrai che funziona perfettamente, appunto perche' qualsiasi
nome racchiuso tra (") diventa un nome utente banale.

e funziona anche questa:

INSERT INTO "insert" ("select", "where", "from", "join")
   VALUES (1, 2.5, 'alfa', 'beta');

please, nota la finezza: "doppi apici" per delimitare i NOMI,
'singoli apici' per delimitare le costanti stringa (testo).

naturalmente l'escaping per raddoppio vale anche per i doppi
apici: se mai ti venisse voglia di definire una colonna o
tavola che contiene un carattere (") al suo interno, lo devi
mascherare per raddoppio. p.es.:

ALTER TABLE "insert" RENAME TO "studenti del liceo ""giulio cesare""";

N.B.: questo dice lo standard SQL.
se pero' vuoi incapsulare queste espressioni SQL all'interno di un
qualsiasi linguaggio di programmazione, devi sommare i criteri di
escaping del tuo linguaggio con quelli di SQL.
se p.es. vuoi incapsulare il comando SQL di cui sopra in una
stringa C/C++, allora ti diventera' qualcosa come:

sql_stmt = "ALTER TABLE \"insert\" RENAME TO \"studenti del liceo \"\"giulio cesare\"\"\";");

in questo caso la barra (\) non c'entra proprio nulla con SQL, ma
serve a mascherare i doppi apici dentro alla stringa C/C++.

inizi a pensare che e' tutto un casino spaventoso ? yes, sei nel giusto :smiley:

ma con un po' di perseveranza, di attenzione e di pazienza alla fine se insisti
scoprirai che e' tutto perfettamente logico e razionale

ciao Sandro

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Il giorno gio, 08/03/2012 alle 21.42 +0100, a.furieri@lqt.it ha scritto:

On Thu, 08 Mar 2012 21:21:38 +0100, Salvatore Larosa wrote:
> CREATE TABLE (id serial, nome text);
>
> la tabella avrà due campi [id] e [nome]. Se modifichi il campo [nome]
> e
> lo rinomini in [end] la query non viene eseguita perchè END è una
> cosiddetta reserved word per il linguaggio SQL!
>

Niet !!!
puoi usare tutte le parole riservate che credi ...
pero' le devi "infiocchettare" nel modo standad specificato dalla
sintassi universale di SQL.
N.B.: "universale", vale per sqlite, postgres, M$ access etc etc

Era un semplice esempio (anche se non universale) per inculcare il concetto
di "escape" o 'escape' :wink:

Glielo vogliamo far capire @PDD come tradurre, o "èscappato"? :smiley:

Saluti