access e php

[Sholn]

Apro questo post per chiedervi qualche consiglio, la situazione è questa.
Devo fare una pagina in php che legge dei dati da un database di access salvato su un pc. La scelta è obbligata per vari motivi:
Il db in questione gestisce gli ordini di un negozio e lavora con un programma in vb, il sito servirebbe ad aggiungere altri ordini nel solito db.
Dato che fare una sincronizzazione access-mysql mi sembra più complesso che accedere direttamente ad access e che non mastico per niente asp....
Consigli in merito? e soprattutto, è fattibile?
grazie

[Sholn]

la cosa è fattibile se qualcuno è interessato posto il codice di base.

[scostante]

Se non sbaglio ADOdb gestisce anche Access. Di sicuro tramite ODBC, non so se direttamente su file.

Io però generalemente faccio il contrario, db su mysql in remoto (o meglio, vicino al web server) e se proprio vogliono farsi del male con vb per le procedure da ufficio collego mysql in ODBC su tunnel ssh. Più che altro in un caso simile mi sono posto il problema: se cade l'host con il db access o cambia ip o va anche solo in timeout causa spyware, worm, eccesso d'uso di youtube et similia che capita al lato web? Rischi di perdere l'ordine, no?!?

[Sholn]

Originariamente inviato da scostante

Se non sbaglio ADOdb gestisce anche Access. Di sicuro tramite ODBC, non so se direttamente su file.

Io però generalemente faccio il contrario, db su mysql in remoto (o meglio, vicino al web server) e se proprio vogliono farsi del male con vb per le procedure da ufficio collego mysql in ODBC su tunnel ssh. Più che altro in un caso simile mi sono posto il problema: se cade l'host con il db access o cambia ip o va anche solo in timeout causa spyware, worm, eccesso d'uso di youtube et similia che capita al lato web? Rischi di perdere l'ordine, no?!?

ho le mani legate purtoppo, il programma che gestisce e visualizza gli ordini utilizza un db access, dato che non posso modificare il programma (altrimenti spostavo tutto su un db remoto mysql utilizzato anche per il sito e finiva il discorso) mi trovo costretto a dover modificare il db dal sito.
Un problema in più è, come faccio a far accedere lo script del sito sul db del pc?, purtoppo penso sia un gran macello ,sempre che sia possibile.

Pensavo quindi di hostare la parte del sito relativa all'inserimento degli ordini direttamente sul pc dove risiede il .mdb tramite un server apache.
Nel caso in cui il pc fosse affetto da virus/spyware o problemi di connessione non sarebbe lo stesso possibile reperire gli ordini effettuati se il db fosse sul sito (con la differenza che verrebbero inseriti ma non evasi)
Per quanto riguarda l'ip dinamico del pc mi basterebbe utilizzare un servizio come dyndns per essere a posto.
Per quanto brutta mi sembra una possibile "soluzione" ,più che altro un accrocchio,che ne dici?
Semprpe che riesca a capire come inserire correttamente i dati nel db senza il programma

altri consigli?

[scostante]

Sì sì, come accrocchio non è male...
Per leggere e scrivere sul file di access credo che tu abbia comunque bisogno di installarlo come dsn in odbc, che è una cosa piuttosto banale. Fatto quello usi la tua libreria o adodb e non dovresti avere grosse difficoltà. Anzi, usando adodb hai il vantaggio dell'astrazione: se domani passi a mysql cambi il dirver adodb e sei a posto. Accedere direttamente al file mdb... beh, può darsi che esista una libreria in php per farlo, ma onestamente non lo farei nemmeno come accrocchio, specialmente in produzione. Se lavori in remoto idem, ma *devi* avere un tunnel, e senza shell sul web server non puoi farlo.

Io comunque non butterei via l'idea di gestire tutta la parte web da un lato e quella db dall'altro. L'ipotesi di sincronizzare due db, per quanto orribile, penso sia la più pratica e flessibile, o almeno io l'avevo pensata così in un caso simile: applicazione web a mio gusto con il suo db + accrocchio di sync sull'host con il db locale, utilizzando la connessione solo in un senso per ogni tabella (o "leggi dalla A" o "scrivi sulla B") la sincronizzazione dovrebbe essere affidabile - chiaro che se vuoi aggiornare sul web i dati di un ordine modificandoli dall'host con il db access la cosa è ben più complessa.

Si potrebbe creare un db di access vuoto e collegare le tabelle ordini ed articoli dal db di produzione. Crei una macro che apra una query di questo tipo per accodare sulla tabella degli ordini i contenuti di un file di testo: http://www.sitocomune.com/queries/queries021.htm e butti lì anche una macro che esporti in maniera più o meno automatica il csv degli articoli da uploadare sul sito - sul Sitocomune dovresti trovare qualcosa di già pronto.

Utilizzando quel miracolo di cURL si potrebbe tirare su un wrapper all'applicativo access in batch dos tipo (vado a memoria, la sintassi avrà qualche errore):

@echo off
:: cambiamo nella dir di lavoro

cd c:\sync

:: scarichiamo il csv degli oridini generato direttamente da uno script php
::creato ad hoc e lo salviamo nella directory di lavoro come ordini.csv 

curl -O http://miosito.com/genera_csv_ordini.php -o ordini.csv

::chiamiamo syncdb.mdb da riga di comando facendo eseguire una 
::macro che lancia la query di accodamento sulla tabella ordini locali

access syncdb.mdb /x macro_importazione_ordini

::chiamiamo la macro che genera il csv degli articoli da importare sul web

access syncdb.mdb /x macro_esportazione_articoli

:: postiamo il csv degli articoli tramite uno script php che genera
:: una semplice pagina contenente un form di upload ed un tasto 
:: submit (OK) 

curl -F [email protected] -F press=OK http://miosito.com/upload_csv_articoli.php 

:: finito. Lanciamo l'applicativo vero e proprio
c:\programma_noioso_e_mediocre_in_vb.exe

dove gli script genera_csv_ordini.php e upload_csv_articoli.php altro non fanno che sanitizzare i dati in entrata ed uscita e normalizzarli per il db dell'applicativo web o del db access.

Poi se funziona tutto a dovere metterai in sicurezza il batch con i vari breakpoint del caso e la gestione degli errori, magari chiuderai l'accesso (almeno in upload) al web con utente e password .htaccess (che cURL dovrebbe gestire senza problemi) e blinderai le pagine dall'accesso dei bot dei motori di ricerca.

E' un po' grezzo perchè (per mia fortuna) è rimasto solo un prototipo, però perdendoci un paio d'orette dovresti essere in grado di rendere il batch "trasparente" prima dell'avvio dell'applicativo locale.

Che ne pensi?

[Sholn]

l'idea di sincronizzare due db non mi attrae particolarmente, anzi, mi terrorizza abbastanza! continuo a pensare che il doppio sito sia più semplice e alla fine neanche troppo instabile...
cmq ora nn ho molto tempo per pensarci su, riscrivo domani, grazie mille per l'interessamento

[scostante]

Beh, è un sintomo di un individuo sano reagire male al termine sincronizzazione. Però anche un host windows piazzato in una lan ed aperto verso l'esterno non dovrebbe farti dormire sonni troppo tranquilli!

La cosa che non mi piace molto della tua idea è più che altro dyndns. Non ti dico il casino che mi è capitato quando i miei tunnel ipsec non si alzavano perchè dyndns aveva deciso che i client di aggiornamento dei router non erano più "legali" e di conseguenza, senza nome di dominio, nessuno trovava (o autenticava) più il suo vicino.

Chiaramente, per male che ti vada nel tuo caso, l'utente si ritroverà una "pagina non trovata" e morirà lì, però anche ridirezionare un processo d'ordine su un ip dinamico non è proprio rassicurante, sopratutto visto che ci girerebbero i dati personali dei clienti (mai e poi mai carte di credito, eh!). Se non sbaglio poi alcuni provider non gradiscono che girino server web sugli host collegati alla loro rete (non a caso dyndns dovrebbe avere anche un PAT per la porta da utilizzare) e rischieresti di incorrere in "oscure" policy di limitazione di banda del tuo provider - e in uscita ce n'è già poca. Non so, forse con un ip fisso avresti meno problemi...

[Sholn]

Originariamente inviato da scostante

Beh, è un sintomo di un individuo sano reagire male al termine sincronizzazione. Però anche un host windows piazzato in una lan ed aperto verso l'esterno non dovrebbe farti dormire sonni troppo tranquilli!

La cosa che non mi piace molto della tua idea è più che altro dyndns. Non ti dico il casino che mi è capitato quando i miei tunnel ipsec non si alzavano perchè dyndns aveva deciso che i client di aggiornamento dei router non erano più "legali" e di conseguenza, senza nome di dominio, nessuno trovava (o autenticava) più il suo vicino.

Chiaramente, per male che ti vada nel tuo caso, l'utente si ritroverà una "pagina non trovata" e morirà lì, però anche ridirezionare un processo d'ordine su un ip dinamico non è proprio rassicurante, sopratutto visto che ci girerebbero i dati personali dei clienti (mai e poi mai carte di credito, eh!). Se non sbaglio poi alcuni provider non gradiscono che girino server web sugli host collegati alla loro rete (non a caso dyndns dovrebbe avere anche un PAT per la porta da utilizzare) e rischieresti di incorrere in "oscure" policy di limitazione di banda del tuo provider - e in uscita ce n'è già poca. Non so, forse con un ip fisso avresti meno problemi...

L'Ip fisso risolverebbe molti problemi, sono daccordo su tutto ciò che dici, l'unico motivo per cui considero questa soluzione è che non crea il problema di non-sincronizzazione, mi spiego, se l'ordine lo puoi fare allora risulta nel db principale, se ci sono grane non riesci a fare l'ordine.
Dato che si tratterebbe di ordinare una pizza, male male il cliente alza la cornetta e fa uno squillo, niente di pazzesco.
Per il pagamento pensavo o di non metterlo dato che c'è la consegna o il ritiro come occasione di pagamento, o cmq utilizzare paypal di modo da dirottare la parte pagamento su un sito sicuro (ed evitarsi tutte le problematiche sui dati anagrafici e della carta).
Potrebbe andare no?

[scostante]

Sì, effettivamente se si tratta di ordini di quel tipo sono decisamente più d'accordo sull'usare il tuo metodo... decisamente più semplice. Anche se la cosa in sè mi spingerebbe molto a valutare una soluzione push, magari anche solo con i socket in php... No, basta casini . Dai, con qualche riserva, ma te l'appoggio!

[Sholn]

Originariamente inviato da scostante

Sì, effettivamente se si tratta di ordini di quel tipo sono decisamente più d'accordo sull'usare il tuo metodo... decisamente più semplice. Anche se la cosa in sè mi spingerebbe molto a valutare una soluzione push, magari anche solo con i socket in php... No, basta casini . Dai, con qualche riserva, ma te l'appoggio!

ora l'unico problema è capire come è stato strutturato il database access