Newsgroup: it.comp.appl.access
Titolo: Formalismi di Access e VBA: una gran perdita di tempo

Ultimamente mi capita spesso di incazzarmi per una virgola che doveva essere
un punto e virgola, un punto che doveva essere un punto esclamativo, un
Forms!maschera! che ci vuole in certi casi e non e' necessario in altri, gli
innumerevoli Iif che bisogna ficcare qua e là perche' lui ha orrore del
null, per non parlare delle stringhe SQL infarcite di
"doppioapiceapicedoppioapice" e non si capisce mai se esegue o non esegue
una query, e quando pensi di no te la fa sotto il naso e ti cambia le carte
in tavola... e le numerose incoerenze del generatore di espressioni rispetto
a VBA...
ecc.ecc. che palle! e lasciatevelo dire da uno che si e' fatto il Fortran,
il Cobol, il Pascal, il C ecc.ecc. ognuno con le sue brave paranoie
formalistiche, da questo punto di vista VBA e' in buona compagnia. Finche'
mi dite che in una formula algebrica bisogna stare attenti alle parentesi,
ok, ma non vi pare che tutte le stronzate suddette siano perfettamente
inutili e servano solo a far perdere tempo?
e scusate lo sfogo, dipende dal particolare momento topico in cui non riesco
a progredire e sto perdendo del gran tempo... tanto lo so che non serve a
niente, dopo essersi fatto un mazzo un po' di volte uno impara tutti i
trucchi e si dimentica che all'inizio si incazzava
barbi

 barbi
Capisco il tuo sfogo, ma come hai avuto modo di leggere su questo NG (o su
ICDA), pochissimi sono i problemi che riguardino Access, che siano rimasti
irrisolti.
Tutto ciò sicuramente per la preparazione dei frequentatori, ma anche per
la duttilità di uno strumento come Access.
Ciao RoDAgo ;-)

una query
Bhč, questo č un problema comune a qualsiasi linguaggio debba lavorare
con statement sql; non č che programmando in Cobol le cose vadano poi
meglio anzi! Hai anche la rottura delle host-variables e dell' enorme
formalismo (questo sě) del linguaggio....
Se vuoi evitare il "supplizio" basta evitare gli statement sql, x quanto
comodi
non sono affatto indispensabili....
Bye, Ste


ma come evitare SQL?
barbi

ma come evitare SQL?
Ma..., ad esempio con qualcosa tipo:
set rs = db.openrecordset("NomeTabella", dbOpenTable)
rs.Index = "PrimaryKey"
rs.seek "=" ValoreRicerca
.........
Qua di sql non ce n'è nemmeno un pò, anche se a me
pare un codice decisamente meno "flessibile"....
Bye, Ste


...e se devi fare una unione di tabelle? Una query di questo
tipo puoi farla solo in SQL, con Access... (istruzione UNION)...
L'SQL non è completamente eliminabile e non ritengo nemmeno
necessario farlo... basta impararlo: ha poche semplici regole...
Micio

 Micio
Sono d'accordo con te Micio, il dialetto Sql di Access ti consente di creare
tante cosine celermente e come lo stesso Bettini scrisse, in modo più
flessibile.
Anche perchè per ricorrere alle Seek, devi per forza avere il tuo bravo
indice, ed in sostituzione il Find mi sembra lentuccio!
Studiando e sbagliando si impara e le regole se ci sono un motivo dovrà pur
esserci!
A tal proposito cito:
Non mi scoraggio, perchè ogni tentativo sbagliato,
scartato è un altro passo avanti.
(Thomas A.Edison)
Ciao a tutti
RoDAgo

necessario farlo... basta impararlo: ha poche semplici regole...
Come già detto sono assolutamente d'accordo sul fatto che
sql facilita le cose (infatti io lo uso pesantemente); sono xò
altrettanto sicuro del fatto che non sia strettamente necessario,
ho lavorato x anni in ambienti di sviluppo non sql-oriented....
L'esempio della union xò è un pochetto infelice, è fattibile anche
via codice gestendo come si deve 2 recordset anche se ovviamente
in sql è infinitamente + semplice.... xò è una cosa che non si dovrebbe
fare mai! Le prestazioni diventano pessime (a meno che non siano 2
tabelline insignificanti) e nel 99.99% dei casi indica un disegno sbagliato
dell' architettura.
Bye, Ste

dell' architettura.
ok, allora come al solito non è che un metodo sia più
sbagliato di un altro, che un linguaggio sia migliore di
un altro ecc... dipende sempre cosa si deve fare,
non sei d'accordo?  :-)
Anch'io se devo fare qualcosa di più complesso uso
semplice codice VBA, ma se posso usare un po' di
"codice SQL" (dove posso) lo faccio...
Micio

 un punto e virgola, un punto che doveva essere un punto esclamativo, un
in sostanza volevo dire: un linguaggio veramente moderno dovrebbe (e secondo
me potrebbe) essere amichevole al massimo, perche' deve facilitare la vita
nella messa a punto, dove non interessa la velocità; dopo si compila, e' una
questione di compilatore... invece i linguaggi, anche nuovi (filone C e
seguenti) sono infarciti di formalismi inutili, di limitazioni assurde,
pensiamo ad esempio in quanti modi si scrive lo stesso stupidissimo IF in
VB, Cobol, C... se appena uno deve programmare in due o tre linguaggi
metterà sempre una parentesi di troppo prima di ricordarsi che e' in VB e
non e' piu' in C. Nel caso nostro di VBA ci sono poi le innumerevoli piccole
differenze con SQL ad avvelenare la vita...
barbi

differenze con SQL ad avvelenare la vita...
anche qui... uno standard sql esiste, ma nessuno e' obbligato a
seguirlo...  perche' ad es. oracle non implementa le join cd. esterne?

 wrote in message
389d81f...@news.interbusiness.it...

guarda, il mio discorso, partendo da un'incazzatura, voleva un po' spaziare
nei massimi sistemi, ossia: proviamo un po' a pensare ai (principali)
linguaggi che hanno inventato, e già qui bisogna risalire a prima dei PC.
Lasciamo pure da parte i vari assembler, microlinguaggi ecc. e anche i vari
ambienti superspecializzati tipo hostcomputers (CICS...) o orientati a
qualche segmento (Delfi...) e consideriamo i cosiddetti linguaggi
"generali": Fortran, Cobol, Algol, Pascal, Basic e il suo filone con le
varianti fino al VB, C e il suo filone con C++, poi Java ecc., tutti ti si
presentano con grandi sparate promo-commerciali dicendo che sono
user-oriented, qualcuno sta più
sull'universitario-con-la-puzza-sotto-il-naso, qualche altro sul pratico, ma
tutti sono stati progettati dal punto di vista del sistemista che deve
pensare a facilitarsi la vita col compilatore, non dal punto di vista
dell'utente che non vuole perdere tempo; e non parliamo della diagnostica di
errore perche' non la finiremmo più... Dal punto di vista di uno che se li
e' passati un po' tutti, mi sembra che le maggiori innovazioni sono venute
col C, che peraltro e' il meno amichevole, e colla programmazione ad
oggetti, ma nessuno ha rinunciato a quegli irritanti formalismi di cui sono
convinto che si potrebbe benissimo fare a meno... anche se qua e là si
vedono casi di convergenza, linguaggi che implementano caratteristiche e
prestazioni tipiche di un altro... si potrebbe anche pensare che
darwinianamente possa alla fine sopravvivere un solo linguaggio che prenda
il meglio da tutti...
ma allora sarebbe troppo facile e le SH come farebbero a fare la lira
:-))))) ?
barbi

:-))))) ?
naa... non credo che sia questo il modo di fare la lira... invece di
vendere pochi pezzi a molto meglio vendere molti pezzi a poco.