@stellina: posta l'istruzione completa
@gibra: a me pare corretta - come andrebbe scritta secondo te?
@stellina: posta l'istruzione completa
@gibra: a me pare corretta - come andrebbe scritta secondo te?
Appunto...Originariamente inviata da optime
Come fa ad essere corretta, se i nomi dei campi NON possono contenere il punto ?
Caso mai dovrebbe essere qualcosa del genere:
Giusto?codice:select * from [tabella] where [campo] = Replace(valore, '.', '')
Devo insistere!!!
codice: select*fromNomeTabellawherereplace(campo,'.', '') like'%valore%'
In questo modo se in un campo ho memorizzato una sigla tipo U.S.L. e voglio dare modo all'utente pigro di cercarla mettendo nella textbox USL, con questa funzione la troverà lo stesso.
E ripeto: FUNZIONA!!! Sul PC dove è installato Office 2010 FUNZIONA, mentre sull'altro no, dicendo che non riconosce la funzione REPLACE.
Puoi insistere fin che vuoi.
E' completamente sbagliata, e la tua spiegazione ne è la prova, senza ombra di dubbio.
Comunque ritengo inutile continuare questa discussione.
Come detto da oregon, temo ci sia un misunderstanding... non ho riferimenti sul dialetto SQL di Access, ma una funzione del genere esiste ad esempio in SQLite, e quel codice sarebbe assolutamente corretto. Per ogni record, il DBMS prende il contenuto del campo campo ed elimina tutti i punti prima di confrontarlo con la clausola like. Ovvero, ovviamente non opera sul nome del campo, ma sul suo contenuto (come qualunque funzione che si possa richiamare in SQL).
Amaro C++, il gusto pieno dell'undefined behavior.
Appunto! MItaly, mi hai appena dato ragione!
Infatti la regola è che:
prende il contenuto del campo campo
La questione NON E' se la funzione Replace() esista o meno; ci mancherebbe altro che dopo 15 anni di programmazione non la conoscessi!!!
Il problema è che NON E' POSSIBILE usarla in quel modo, e francamente trovo davvero strano che nessuno se ne sia accorto.
Stellinaxxx la usa facendo il Replace sul NOME del campo della tabella, NON sul contenuto del campo; il che non ha senso.
Ammesso, e non concesso, che in Access puoi scrivere i nomi dei campi come ti pare basta che poi nelle query questi siano inclusi tra parentesi quadre, non ha comunque senso fare il Replace sul nome del campo, lo si deve fare sul contenuto.
Questa non è un'opinione. E' un fatto.
Tra l'altro, poi, è lo stesso stellinaxxx che afferma di volerla usare per tale scopo:
solo che la stringa SQL riportata è sbagliata.
Suggerirei di prestare più attenzione a quello che si legge, e si scrive.
È esattamente quello che vuole fare, come ribadito più volte; nel primo post ammetto che era poco chiaro e anch'io non avevo ben capito, ma poi si è chiarita perfettamente.Appunto! MItaly, mi hai appena dato ragione!
Infatti la regola è che:
prende il contenuto del campo campo
È ben quello che sta facendo! Infatti se specifichi il nome di un campo (che in Access, come in praticamente ogni altro DBMS, si può specificare senza quadre, se questo non introduce ambiguità) nella clausola WHERE, questo viene interpretato come il contenuto di quel campo sul record che è correntemente in esame; ma queste sono le basi di SQL, che so per certo che conosci a menadito, per cui non capisco da dove nasca l'equivoco (specie quando già in quattro ti abbiamo fatto notare che hai preso un abbaglio sull'uso che intende fare di quella query).Ammesso, e non concesso, che in Access puoi scrivere i nomi dei campi come ti pare basta che poi nelle query questi siano inclusi tra parentesi quadre, non ha comunque senso fare il Replace sul nome del campo, lo si deve fare sul contenuto.
stellinaxxx vuole fare una specie di fuzzy-matching sul contenuto di una certa colonna; ovvero, nel DB in una certa colonna i nomi di diverse organizzazioni (sparo a caso) sono memorizzati con i punti tra le lettere delle sigle (ad esempio S.p.A., A.S.L., U.S.L.), e vuole che la ricerca matchi anche quando l'utente inserisce, come stringa da cercare, l'equivalente senza punti (SpA, ASL, USL). Per fare questo invece di fare un confronto del tipoTra l'altro, poi, è lo stesso stellinaxxx che afferma di volerla usare per tale scopo:
(dove campo è una colonna di NomeTabella)codice:select * from NomeTabella where campo like '%valore%'
vuole fare
ovvero, ad essere confrontato tramite la like non è il contenuto della colonna campo "così come è memorizzato nel DB", ma per ogni record il confronto avviene tra '%valore%' e il contenuto del campo campo "epurato" dai punti.codice:select * from NomeTabella where replace(campo,'.', '') like '%valore%'
Non posso che essere d'accordo con questo suggerimento.Suggerirei di prestare più attenzione a quello che si legge, e si scrive.
In ogni caso, incidente chiuso, si torna in-topic, altrimenti non ne usciamo più.
Ultima modifica di MItaly; 10-10-2013 a 20:24
Amaro C++, il gusto pieno dell'undefined behavior.
Ebbene, devo confessare di aver 'cannato di brutto'.
Il mio problema era dovuto al fatto che ero partito da un assunto 'diverso', e ciò mi aveva messo un bel 'bisteccone sugli occhi' impedendomi di vedere invece come stellinaxxx intendeva utilizzare la funzione.
Ancora una volta 'mi sono dimostrato' che prima di parlare bisogna verificare quello che si afferma con un test pratico; ma quello che mi fa imbestialire di più è che lo so, ma ogni tanto ci casco come un pivello.
Ben mi sta, anche se, ad onor del vero, in questo caso non avrei potuto fare test semplicemente perchè Replace non funziona sul mio Office 2010 (appena testato).
Quindi chiedo scusa a tutti, in primis a stellinaxxx, per il fraintendimento e mi rammarico di avere fatto 'sta figuraccia.
Tornando in topic:
purtroppo non sembra esistere soluzione al problema di: Funzione non definita...
Di norma non uso funzioni Access nelle query, l'unica che ho usato in passato fu Round in una procedura di aggiornamento listini che ha funzionato fino a che nel pc avevo Office 2007.
Dal momento in cui ho installato Office 2010 non funzionava più, quindi ho dovuto mettere mano al codice.
Non dipende dalla versione del database usato, ma dal motore della versione di Access presente nel computer, il che significa che se il cliente decide di aggiornare da Office 2003 ad Office 2010 si troverà questa 'bella' sorpresa, e ovviamente la prima cosa che farà è contattare noi, accusandoci con un: Non funziona più!
La causa è dovuto al fatto che Microsoft ha reso Private alcune funzioni che prima erano Public, di fatto rendendole accessibili solamente dall'interno dell'ambiente MSAccess.
Dall'esterno: ci si attacca al tram.
Insomma, i soliti graditi regali di Microsoft, alla faccia della compatibilità.
Questo promette di risolvere il problema:
Use sandbox mode in Access 2007 - Access - Office.com
http://office.microsoft.com/en-us/ac...010167429.aspx
Ma, a parte il fatto che non risolve nulla (appena testato) è comunque troppo invasivo perchè richiede la modifica al Registro di Windows, il che non è detto che sia sempre applicabile.
Per chi, come me, distribuisce programmi ai propri clienti non è detto che i permessi dell'utente consentano tale modifica al Registro, con il rischio di dover provvedere 'a mano' su ogni computer di ogni cliente.
Lo avevamo capito ...... ma può capitare ...
No MP tecnici (non rispondo nemmeno!), usa il forum.
codice:
select * from NomeTabella where replace(campo,'.', '') like'%valore%'
Rispondi quotando
