Newsgroup: it.lavoro.professioni.webmaster
Titolo: Aiuto stringa connessione DB su altro dominio...

Ciao a tutti,
mi chiedevo se fosse possibile da una pagina aspx in un dominio
www.dominio.it
 connettersi a un DB su un dominio diverso
www.altrodominio.it
, in questo modo:
String Connessione = "Provider=Microsoft.Jet.OLEDB.4.0;Data
Source=
http://www.altrodominio.it/a.mdb
";
Io ho un errore di questo tipo:
Nome file non valido.
Descrizione: Eccezione non gestita durante l'esecuzione della richiesta Web
corrente. Per ulteriori informazioni sull'errore e sul suo punto di origine
nel codice, vedere l'analisi dello stack.
Dettagli eccezione: System.Data.OleDb.OleDbException: Nome file non valido.
Grazie...

 Grazie...
l'errore è ben chiaro "nome di file non valido" e quindi file non trovato 
copia il tuo db all'interno del server web e mi raccomando attiva i diritti 
in scrittura allo stesso
-- 
ITHost (your host company)
Technical Manager
C. Paparelli (MCSE,MCSD,MCDBA)
http://www.ithost.ch
 

 Source=
http://www.altrodominio.it/a.mdb
";
per fortuna non è possibile farlo con i file database come access.
se vuoi accedere a database su server diversi hai bisogno di interfacciarti
con server database come sql server, oracle, db2...
-- 
Lino Mari
http://www.ebow.it
 - e-business on web!
http://www.ebow.it/blog/
 - Mktg Log
http://www.dev2dev.it
 - La rete ha connesso nuove particelle - d2D004

 diritti in scrittura allo stesso
Mi confermi che comunque non posso farlo?


non ti fidi di me?


 Mi confermi che comunque non posso farlo?
si a meno di non voler usare RDO ma per motivi di sicurezza e supporto 
futuro sconsiglio caldamente
Testualmente "Attualmente Microsoft non prevede di sviluppare ulteriormente 
RDO. Per questo motivo per l'accesso ai dati può essere preferibile 
ricorrere ai controlli basati su ADO anziché ai controlli RDO." estratto da 
http://msdn.microsoft.com/library/ita/default.asp?url=/library/ITA/vccore/html/vcrefrdodatabindingvsadodatabinding.asp


 futuro sconsiglio caldamente
Non sono "completamente" d'accordo. Parzialmente si, nel senso che è
corretto dire che tramite ADO "liscio" non si può - ma trovo non
corretto dire che tramite ADO assolutamente non si può.
Cerco di spiegarmi: ADO ha una caratteristica(una delle poche, imho)
molto utile e sensata che è il modello briefcase. Praticamente, si può
salvare un recordset ADO in formato XML per utilizzarlo in locale.
Questo è l'uso che originariamente se ne voleva fare. Però nessuno
impedisce di usare questo approccio(con un Content-Type "text/xml") per
utilizzare un DB access da un altro dominio.
Questo però presuppone che si possa modificare il sito presente
sull'altro dominio per rendere questa iterazione possibile.
Ciao,
Andrea

 sull'altro dominio per rendere questa iterazione possibile.
uhm leggi un po' RDO che è nato proprio per queste


 tabella set campo1=123, campo2="pippo" where pk=12
allora il sistema da te descritto coninvolge le parti di ado e precisamente 
jro e rdo con i quali è possibile "aggiornare" un db in remoto con 
connessione internet, ma è ben diverso da una connessione tcp infatti è 
pensato per la sincronizzazione delle repliche, oltre tutto apre non pochi 
buchi di sicurezza sul web server in quanto deve venir installata la vfolder 
mdac per permettere l'accesso dall'esterno con tutti i diritti aperti, in 
casi limite è consigliabile attivarlo ma affiancato a ipsec in modo da 
autorizzare unicamente determinati ip ed inoltre facendoli transitare su un 
canale sicuro
Se l'obiettivo di "hjonon" è quello di avere il db sul server A e il sito 
sul server B che interagisce direttamente con il db c'è solo un alternativa, 
ovvero cambiare db e utilizzare un rdbms come già consigliato nei post 
precedenti, la scelta è ampia per tutti i gusti e tasche :-P


 volteggi acrobatici e scomodare xml
Senza dubbio, infatti l'idea č di usarlo un pň per tutto, non
solo per le select. Quanto al fatto che non bisogna per forza
scomodare XML siamo anche d'accordo, sempre che non si voglia
avere un sistema "universale" che possa anche visualizzare i
dati nel browser oltre renderli disponibili per un client dedicato.
Ciao,
Andrea

 dati nel browser oltre renderli disponibili per un client dedicato.
uhm xml è un ottimo sistema per scambiare dati ma mi sembra stupido 
complicarsi la vita quando puoi benissimo migrare i db in msde che oltre ad 
essere gratuito è un vero rdbms


 essere gratuito è un vero rdbms
Beh, usare un formato custom da XSLizzare(brrrr... che
termine... :-P) in XHTML può essere una buona idea per dare la
possibilità di avere sia i dati che una pagina Web, just in case.
Quanto al trasformare un DB Access in uno MSDE, personalmente non ho mai
amato l'upsizing wizard di Access(anche perché non sempre funziona come
dovrebbe...) e considerate le profonde differenze concettuali tra un
"vero" RDBMS ed Access penso che a quel punto valga la pena rifarlo il
database.
Inoltre si pone il problema di importare il DB in remoto e non so
quanto SQLServer sia "affidabile" nelle repliche MSDE/SQLServer o
viceversa.
Ciao,
Andrea

 viceversa.
ehm msde e sqlserver sono la stessa cosa unicamente il primo non ha i client 
e ha un workload governor ma di fatto è sql server e pertanto le repliche 
funzionano benone


 funzionano benone
Ti pare poco che non ha i client? <g> Comunque Andrea Montanari ha un
corrispondente di Enterprise Manager per MSDE(DbaMgr).
Quanto alla struttura, sono d'accordo che sono a livello di motore quasi
uguali(anche se non proprio identici al 100% visto che quello MSDE oltre
cinque client incomincia a rallentare in modo vistoso).
Sulla funzionalità delle repliche ti prendo in parola, il mio è un
dubbio "di principio", con MS non si può mai sapere a priori :-P
Ciao,
Andrea

 uhm per progetti medio piccoli un upgrade va benissimo
Sempre che i requisiti siano abbastanza flessibili, imho.
Casi nemmeno troppo rari come ad esempio integrità referenziale
d'accaio ed uso di SP, l'upsizing wizard non basta e bisogna
ritoccare "a manina" anche normalizzando il DB ulteriormente.
MS non ha una "storia" molto felice con i suoi Wizard, imho,
avendoli provati un pò tutti(da Word a VB6, SQLServer, Access,ecc).
Ciao,
Andrea

 cinque client incomincia a rallentare in modo vistoso).
idem come sopra il workload governor č volutamente installato altrimenti di 
versioni complete non se ne vendono piů
buona lettura
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/architec/8_ar_sa2_0ciq.asp


 avendoli provati un pò tutti(da Word a VB6, SQLServer, Access,ecc).
uhm il punto di forza di access è sempre stata la semplicità oltre a 
soprattutto imho il miglior generatore di query visuale in commercio


 soprattutto imho il miglior generatore di query visuale in commercio
Personalmente non amo i generatori di query, l'idea che tu possa
fare una query senza sapere che cosa stai facendo(drop <> delete) non mi
rende particolarmente entusiasta. Il problema è che se sai cosa stai
facendo non hai probabilmente bisogno del generatore :-) Inoltre, quando
possibile, trovo sempre più comoda la tastiera del mouse.
Ciao,
Andrea

 facendo non hai probabilmente bisogno del generatore :-)
si ma vuoi mettere il vantaggio di dare al commerciale rompi scatole che 
vuole 2000 report la possibilità di renderlo autosufficiente è di grande 
vantaggio questo non vuol dire che il commerciale diventerà in 4 giorni un 
guru di sql


 guru di sql
Qui non si parla di Guru SQL, si parla semplicemente di non lasciare il
commerciale in braghe di tela a doversela vedere con un linguaggio che
probabilmente mai riuscirà a conoscere a sufficienza e per di più magari
dovrà pure studiarsi com'è strutturato il database.
Il problema di fondo è che certe cose(vedi, i report) dovrebbero essere
fatte da personale assunto appositamente(normalmente si chiama "di
supporto") che svolge assistenza interna ed esterna.
Sinceramente io non lascerei fare un report ad un commerciale *mai* a
meno di non essere certo(di prima mano) che è in grado di farlo(aka: un
programmatore che fa il commerciale e che sa che sta facendo) oppure
ricevendo un ordine Superiore con la S maiuscola(ma lì non ci puoi
fare nulla).
Tutto, ovviamente, IMHO.
Ciao,
Andrea