Newsgroup: it.comp.lang.delphi
Titolo: Delphi 2005 e Aruba (terza parte)

Innanzi tutto:  BUON NATALE a tutti.
Eccomi alla terza e ultima parte delle mie prove 
ASP.NET
 con D2005;
riguarda la pubblicazione di una minima applicazione D2005 con accesso
ad un file Access .MDB. su server web condiviso Aruba.
Gira che ti rigira non riesco a fare diversamente da questo:
1. creare una pagina aspx con relativo code-behind  .pas
2. inserire i controlli BDPConnector, BDPDataAdapter, DBWebDatasource e
Dataset
3. Collegare tra loro i vari componenti, secondo la consueta logica Borland
4. Eseguire, con successo, sul server web Cassini in locale la pagina aspx
creata
5. Fare il deployng "assistito" sul server web Aruba
poichè chiaramente su Aruba non funziona, attivo la visualizzazione degli
errori.
 a mano a mano che leggo i messaggi di errore faccio l'upload nella cartella
\bin di:
6.  Borland.Data.Web.dll
7.  Borland.Data.Common.dll
8.  Borland.Data.Msacc.dll
ecc.. (non me li sono segnati tutti)
fino all'ultimo: l'imbattibile, insuperabile, inossidabile, invincibile
BDPMSA20.dll
che non viene caricato anche se cè, con il messaggio:
------
Unable to load DLL (bdpmsa20.dll).
Description: An unhandled exception occurred during the execution of the
current web request. Please review the stack trace for more information
about the error and where it originated in the code.
------
e nello stack riporta:  BdpException: Unable to load DLL (bdpmsa20.dll ....
quindi è colpa di BDP.Data.Provider.BDPConnection
Come evitarlo ?
Ho capito che Aruba non vuole altro che connessioni ODBC. Ma come farla ?
Come evitare di utilizzare la sfilza di componenti di cui all'inizio ?
Non ho trovato nessun altro modo per aprire un file da una pagina web-D2005
Sono anche rimasto un pò "scocciato" perchè ho capito (finalmente, direte
voi) che il codice
*dentro* la pagina aspx è C# o VB anche in D2005. Ma allora a che mi serve
D2005/
ASP.NET
 ?
Va bene 
VCL.NET
 ecc.. ma mi sembra che con 
ASP.NET
 vale sempre l'ambiente
VB. O no ?
Grazie per l'attenzione e ancora tanti auguri a tutti
GP

 GP
Andrea

 Grazie per l'attenzione e ancora tanti auguri a tutti
Auguri di Buone Feste anche a te! :-)
-- 
Marco «Alka» Breveglieri
(marco [@] abls [.] it )
  ABLS Team S.n.c. - Software & Web
  42019 Scandiano (Reggio Emilia)
 
http://www.abls.it

 scelta di base sbagliata. 
Perché mai ? che ha ODBC che non va ?
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 Perché mai ? che ha ODBC che non va ?
Perché esistono tante altre possibilità, sia sotto Windows che
sotto Linux. Un esempio: per MySQL esiste un provider ADO.
ODBC ormai è un pò anzianotta come tecnologia e credo che ADO,
pure con tutte le sue idiosincrasie e particolarità, sia una
scelta migliore, considerando che ODBC non durerà in eterno e che -
almeno apparentemente - sembra che le scelte di Microsoft si dirigano
verso 
ADO.NET
, che è sicuramente molto più simile ad ADO che non ad
ODBC.
Ciao,
Andrea

 ODBC.
Credo che la scelta di Aruba sia basata su motivi di stabilità; 
evidentemente, l'uso di ODBC - a quanto si legge - provoca meno problemi 
di OLE DB quando i clienti installano pacchetti software conosciuti che, 
in caso di errore, sembrano bloccare completamente il server, 
costringendo Aruba ad arrestare e isolare il sito Web incriminato.
Ciao! :-)


 Ciao! :-)
Ciao
Andrea

 sotto Linux. Un esempio: per MySQL esiste un provider ADO.
ODBC è uno standard, ADO no.  Questo è un grosso vantaggio dal mio punto
di vista.  ADO risponde, e risponderà ancora e per molto tempo, al modello
COM, che non è supportato su tutte le piattaforme.  E poi ADO, a quanto ne
so, è ancora bello pieno di bug.  Di tecnologie "anzianotte" ce ne sono
parecchie in giro, l'importante è che funzionino.  Sinceramente, mi
aspetterei delle motivazioni ben più sostanziose.


 aspetterei delle motivazioni ben più sostanziose.
Sicuramente di tecnologie anzianotte ce ne sono tante, ma il mondo Web è
giusto un attimo diverso da quello mainframe, tanto per dire.
Inoltre per moltissime di quelle tecnologie non viene fatto più molto
nuovo sviluppo(tranne che per casi moooolto particolari).
Quanto al fatto che ODBC sia uno standard, non discuto, ne discuto però
l'efficienza rispetto ad altre soluzioni più "targhettizzate" al tipo di
ambiente cui si aderisce.
La dicotomia Windows/Unix è talmente incolmabile che, pur esistendo la
tecnologia medesima per entrambi, viene usata in modi completamente
diversi. L'unico modo "semplice" da Delphi per utilizzare ODBC è
comunque passare per ADO. Altrimenti bisogna usare il BDE(auguri...)
oppure comprare componenti di terze parti.
Non mi risulta che esista, in Delphi, altro modo di usare ODBC.
Però non ho mai indagato, qualche prova "mirata" la farei volentieri.
Posto che comunque il tutto debba girare sotto windows, ADO
secondo me ha più senso di ODBC. Vorrei far presente che, per
quanto - ad esempio - Kylix renda il port sotto Linux enormemente più
semplice, restano molti dettagli diversi e non è così automatico
"fare il cambio". Utilizzando PHP, potrei capire di più l'argomento che
ODBC è uno standard, ma usando Delphi - onestamente lo comprendo molto
meno. Ed io certo non sono contro gli standard, anzi, però secondo me
vanno contestualizzati nella situazione reale.
Se usi Delphi, sotto windows, ODBC secondo me non è la soluzione
migliore, a patto che ve ne siano altre(come un provider ADO).
Può non piacere, ma è così secondo me.
Il tutto senza contare il fatto che ODBC, essendo parecchio anziano,
probabilmente(ma non ho indagato) non è stato aggiornato per supportare
molte cose che noi oggi riteniamo "normali" per un DBMS.
Ciao,
Andrea

 [...]
Chi non ha avuto controversie con un'azienda? Non credo sia un dato 
significativo, soprattutto considerando il "giro d'affari" di Aruba 
stessa, pertanto č possibile che a volte si aprano dei...contenziosi.
Ad esempio, per quanto mi riguarda non ho mai avuto problemi di alcun 
tipo. :-)
Non so quanto sia corretto giustificare la scelta di una piattaforma di 
accesso ai dati in base alle controversie di alcuni clienti. :-)
Poi, sinceramente, tra ODBC e OLE DB, tra "correre" e "scappare"... ;-)


 meno. 
E' un discorso che vale sempre.  Chi fornisce il servizio di hosting può
pensare alla portabilità dei siti, adottare uno standard garantisce che la
tecnologia server possa passare da Windows a Linux (o viceversa) senza
problemi.  Questo non è un problema da poco.
