Newsgroup: it.lavoro.professioni.webmaster
Titolo: asp: err compilazione

Ecco qui:
Tipo di errore:
Microsoft OLE DB Provider for ODBC Drivers (0x80040E14)
[Microsoft][Driver ODBC Microsoft Access] Errore di sintassi (operatore
mancante) nell'espressione della query ''Descrizione dell'evento bla bla bla
bla bla blabla bla blabla bla blabla bla blabla bla blabla bla blabla bla
blabla bla bla','28/09/2002')'.
La query č:
INSERT into EVENTI(ID_CORSO,TIT_EV,DS_EV,DATA_EV) values
('77','Inaugurazione corso','Descrizione dell'evento bla bla bla bla bla
blabla bla blabla bla blabla bla blabla bla blabla bla bla','28/09/2002')
ID_CORSO numerico
TIT_EV Testo max 255
DS_EV Memo
DATA_EV data formato gg/mm/aaaa
S.O.S !!

 ID_CORSO numerico
e allora per quale motivo metti gli apici ? ;-)

 ha scritto nel messaggio
news:IZw99.8858$pX1.2...@news2.tin.it...



Prima di andare a scrivere sulla tabella usa il replace:
ds_ev = replace (ds_ev, "'", "''")    ' un apice singolo viene trasformato
in doppio apice
Descrizione dell' .....
poverino ... non può certo valutare l'espressione ...
Ciao

 Però tolti gli apici mi da ancora lo stesso errore..
Vedi il post sotto... devi fare anche un replace del testo...


Da un po' preferisco fare
ds_ev = Replace(ds_ev, "'", "&#39;")
Si mantiene un apice ma che non viene rilevato come elemento di "disturbo"
nelle stringhe SQL o nel retrieving di dati da sparare nelle pagine
Claudio


hmmmm ... interessante !!! Controindicazioni?
Mi viene in mente ad esempio che la lunghezza della stringa va in casino ...
Se io ho un campo lungo max 16 caratteri, potrei avere dei problemi con quel
tipo di conversione ovvero perdere una parte della stringa originale.
Alberto

blabla bla blabla bla blabla bla blabla bla blabla bla bla','28/09/2002')
due errori, uno probabile, uno sicuro.  probabile: apostrofo non
raddoppiato nel campo memo.  sicuro: data racchiusa tra apostrofi e
non, come dev'essere per le date, tra segni #.
un consiglio: non passare date nel formato gg/mm/aaaa (o dd/mm/yyyy).
come sai sql è stato inventato da gente anglofona.  per gli anglofoni
la data si scrive mese giorno anno.  se passi una data tipo 28/08/2002
il motore sql di ogni db è abbastanza intelligente per capire che
quello che lui si aspettava come mese (28) sicuramente mese non è,
quindi probabilmente ci sarà un qualche utente europeo che gli sta
passando una data nel suo bizzarro formato giorno mese anno, quindi 08
è il mese e vabbè.
ma se gli passi una data tipo 5 agosto, 05/08/2002, il motore sql si
trova in pasto all'inizio 05, che per lui è una indicazione di mese
valida, cioè maggio, e quello che per te è 5 agosto per lui diventa 8
maggio.
(aspettati casini simili per le cifre con decimali, tipo i prezzi in
euro: gli anglofoni separano le migliaia con virgole e i decimali com
punto, 1,234.56 e non 1.234,56.  del resto da gente che guida a
sinistra e usa misure lineari non decimali che ti vuoi aspettare...
comunque in sql non si separano le migliaia).
passa quindi le date in formato aaaa/mm/gg.  in questo caso il motore
si trova di fronte una cifra che non può essere che un anno, quindi
prende per certo che dopo c'è il mese e poi il giorno.
quindi io riscriverei la tua query in questo modo:
INSERT into EVENTI(ID_CORSO,TIT_EV,DS_EV,DATA_EV) values
('77','Inaugurazione corso','Descrizione dell'evento bla bla bla bla
bla blabla bla blabla bla blabla bla blabla bla bla',#2002/08/28#)
per formattare adeguatamente la data puoi scriverti una funzione che
in vbscript verrebbe tipo così:
function fDataSql(d)
   fDataSql = right("0000" & year(d), 4) & "/" & _
                    right("00" & month(d), 2) & "/" & _
                    right("00" & day(d), 2) & " " 
                    right("00" & hours(d), 2) & ":" 
                    right("00" & minutes(d), 2) & ":" 
                    right("00" & seconds(d), 2)
end function
in effetti la "giustificazione" con gli zeri dell'anno non è
indispensabile, visto che mi pare che la data 0 sia 1899, ma non si sa
mai.

 nelle stringhe SQL o nel retrieving di dati da sparare nelle pagine
Si, ma anzichč 1 carattere ne usi 6...
ora capisco perchč sei cosě cicciottello... ingordo :-D


Sono 5!!!
Mado' dici che i caratteri hanno un alto apporto calorico? :-D
Vabbe' ma prova a usare la stringa con i doppi apici come valore
dell'attributo ALT o TITLE e poi ne riparliamo (a meno che tu non voglia
fare un replace al contrario quando ti serve la stringa in output)
Io gia' faccio casino con gli apici, se mi moltiplichi le volte che in
VBscript devo aprire e chiudere una stringa, e per di piu' controllarne la
presenza nelle stringhe sql, me conviene passa' a  PHP :-D
Claudio


In quel caso resta valida la sostituzione dell'apice con i doppi apici.
Anche se poi comunque sono 2 caratteri e non 1 e quindi ho hai previsto sta
cosa nella predisposizione del campo oppure il problema della lunghezza
della stringa ti si presenta comunque e ti conviene validarla al momento
dell'immissione (lato client).
Se l'apice non c'entra niente in quella stringa, tanto vale che nemmeno la
tratti no?
Col tuo esempio (16 caratteri) mi viene in mente l'immissione del codice
fiscale. Li apici non ce ne devono essere.
Claudio

 fiscale. Li apici non ce ne devono essere.
Cambiamo esempio ... io ho scritto 16 caratteri ma potevano essere anche 30.
Anzi supponiamo siano appunto 30 caratteri (ad esempio campo indirizzo): se
l'utente scrive "via dell'artigianato" o "via dell'artigliere" potrebbe
incorrere in qualche problema. Tu usi 6 caratteri anzichè 1 quindi non puoi
dire che questo sistema sia "bulletproof" ... questo concedimelo. Poi hai
anche dei problemi in editing.
Hmmm ... no, più ci penso e più conviene il sistema tradizionale..
Ciao
Alberto

 anche dei problemi in editing.
No no... mai detto che sia un sistema bulletproof. Ci mancherebbe altro
Comunque dove vedete 6 caratteri in &#39;  ??? :-D
E' vero che nel malaugurato caso ci sia piu' di un apice le cose si
complicano maledettamente ma se leggi la risposta che ho dato a Scano
capisci perche', quando non ho vincoli particolari, preferisco il mio
sistema.
Mi son trovato a dove richiamare delle stringhe contenenti apici da usare
come valori di attributi alt o title.
Esempio scemo
Response.write "<img src='pippo.gif' alt='" & nome_variabile & "'>"
se il valore di nome_variabile contiene un apice mi si tronca la stringa...
Il rimedio sarebbe rinunciare alle virgolette, doppie o semplici, per
racchiudere i valori degli attributi ma io sono abituato a mettercele e
credo sia preferibile usarle.
Claudio


Correzione: non posso togliere le virgolette passando una stringa composta
da piu' parole :-D
Si risolve inframmezzando codice ASP nel codice HTML
<img src="pippo.gif" alt="<%=nome_variabile%>">
Ma in documenti in cui il codice ASP viene richiamato a ogni sospiro so che
e' molto piu' efficiente racchiudere tutto in un bel Response.Write
Claudio

non, come dev'essere per le date, tra segni #.
ah, e ovviamente mi era sfuggito il 77 numerico tra apici che ti hanno
già segnalato.

 ha scritto nel messaggio
news:ak65a6$pd7$1...@lacerta.tiscalinet.it...


 ha
scritto nel messaggio news:qRy99.92466$n04.2...@twister2.libero.it...

puo' risultare comodo in qualche ipotesi, ma scomoda
appena le esigenze vanno oltre la visualizzazione (ad es. editing,
odinamento, etc); oltretutto con una base di dati del genere
hai una una perdita di dati perché non potresti più distingere
l'apice vero e proprio dal gruppo di caratteri &#39; ipotesi rara
(ad esempio un forum sull'Html in cui l'utente deve poter inserire
del codice di quel tipo) più che altro per spiegare perché conviene
avere sempre una base di dati il più 'grezza' possibile.
M.