Driver ODBC / MySql

Grazie infinite per i suggerimenti. Non eccessiva parsimonia, ma FileMaker Server non l’ho mai usato (ricordo di aver fatto una prova con una versione demo anni fa e non capivo neanche cosa fare per avviarlo, perché non partiva, quando partiva perché si era avviato… mi sembrava una specie di Corazzata P.!) e, comunque, probabilmente è sovradimensionato per quello che vorrei fare. Buono a sapersi, comunque.

Riguardo l’accesso: il mio hosting, di base è una chiavica, ma ha alcune chicche. Fra queste mi dà la possibilità di accedere da remoto a MySql e mi consente la connessione ODBC. Unico neo: ho l’ip dinamico quindi, appena cambia, pannello di controllo ed aggiunta del nuovo ip. Ho provato con l’aggiunta di un dns (tipo no-ip, per intenderci), ma credo non piaccia a cPanel e mi tocca togliere il vecchio e rimettere il nuovo ogni volta. Ho anche provato con l’assistenza, ma senza successo.

Grazie ancora per tutte le preziose informazioni e suggerimenti!

Eugenio

dunque, partiamo dalla parte puramente tecnica: si, i driver actual sono robusti, veloci e ben fatti. il fatto che le righe siano tre non cambia molto. Poi, dipende ovviamente dalla quantità: dato che al contrario di FM ( che scarica solo i record visualizzati e i vicini ) MySQL scarica TUTTO il foundset/tabella, se finisci su una tabella da 20 milioniu di record qualche problema di memoria cel’hai. diciamo che finché rimani nel range di migliaia/decine di migliaia di record/tabella non dovresti avere problemi.

In seconda battuta, il discorso della sincronizzazione con WordPress. Li il discorso è un po più lungo e delicato come concetto generale non  hai torto. Fondamentalmente  hai tre strade:

– quella delle ESS che hai iniziato a esplorare, anche se fra formato date e ora, codifica del carattere – specialmente multilingua – ci possono essere parecchie rogne. calcola pure che la maggior parte dei provider commerciali NON consentono la connessione ODBC ai loro DB a meno che tuj non abbia un profilo particolare
– usare un plugin di sincronizzazione come MirrorSync di 360 works che fa il grosso del lavoro (non è gratuito, nemmeno economico e ti serve FMS, ma è un gran bel pezzo di software)
– usi le API proprie di WordPress per interagire mediante URL, magari con baseelements o scriptmaster (che poi è la strada che utilizza la buona lauren kuhlman) e che lascia a WP la paerte sporca del lavoro.

essendomi divertito con tutte e tre le opzioni, posso dirti che sono tutte fattibili, ciascuna con pro e contro, e la scelta di quale utilizzare dipende strettamente dalla tipologia del progetto.

.g.

FilemakerGuru ha la sala mensa?

Alcuni dubbi e considerazioni.

Sto cercando, nel tempo libero, di provare a fare degli aggiornamenti sostanziali ad un sito di un amico. Una ristrutturazione completa, per la precisione.
Farle da interfaccia web risulterebbero estremamente lungo, lento, complesso, faticoso (WordPress con plugin WPML, 4-500 post da creare ”costruendoli” da, in pratica, un csv; come se non bastasse: 5 lingue totali ovvero 4-500 articoli * n_lingue) e, quindi, per risparmiare tempo e per spingere – personalmente – FileMaker oltre la solita soglia anagrafica, fattura, ddt… mi era venuto in mente l’uso di FMP su MySql. Ho già provato a spostare l’asticella con risultati secondo me gradevoli (recupero info da web, invio istruzioni con JSON, eccetera).

Ora, mentre ci ragiono e tento di trovare i giusti driver ODBC, però, mi viene un dubbio. Non tanto sulla fattibilità, quanto sul potenzialmente (o, passami il termine, su ”l’eticamente”) corretto.

Agire direttamente sul database MySql oppure costruire una tabella specchio, compilare questa e solo successivamente ributtare tutto sul database remoto?

Immagino che questa soluzione, anche se più complessa/lunga progettualmente (teoricamente, forse, ma neanche troppo), sia più comoda dal punto di vista di velocità. La compilazione iniziale ed i futuri aggiornamenti avvengono all’interno di FileMaker ed, una volta convalidati, si crea un solo processo di istruzioni/modifiche sulle tabelle remote. A questo punto ci metterà il tempo che ci vuole, ma è solo quello.
Aggiungo: anche aggiungere campi che si rivelassero utili ad un qualche scopo (banalmente: un campo che registra se la modifica è stata trasferita e, quindi, impedisce che venga ricopiato il contenuto del record) rimarrebbero solo in locale così da lasciare quello esterno lindo, efficiente e pulito. Dovrò ragionare sul discorso Media di WordPress, ma è una cosa che penso di sapere come risolvere.

Infine, giusto per chiarire un dubbio prima di acquistare la licenza. Non che sia una cifra destabilizzante, ma per capire cosa aspettarsi. La velocità di risposta che registro ora è quella reale? Mi spiego meglio: ho provato con i driver a 32bit su FM13 ed i processi sono, come hai ben sintetizzato, paragonabili alla fantozziana cinematografia russa d’inizio secolo scorso. Con i driver Actual, invece, la risposta è decisamente più veloce. Certo, non come lavorare in locale, s’intende, ma accettabilissima. È, mi chiedo, giustificato dal fatto che richiama solo tre righe della tabella scelta oppure è effettivamente fatto bene il driver e risponde bene perché … perché sì?

grazie infinite

Che non fosse colpa tua te l’ho scritto dalla prima riga

FM13 Pro è a 32 bit, mentre FM14 Pro a 64. Su windows la cosa è più esplicita (anche se li è schizofrenica l’interfaccia, dato che l’odbc manager per 64 bit sta in una cartelle chiamata system32, mentre quello per 32 bit sta in WOW64… ehm) , mentre su osx meno. e mio parere sul drive mysql per osx è… come dire… diciamo che è analogo a quello di Ugo Rag. Fantozzi sulla cinematografia anteguerra sovietica.

.g.

.g.

Ultimo intervento, giuro.

FileMaker Pro 14 Adv: ho provato praticamente di tutto. Driver MySQL (unicode driver) di più versioni e più architetture, niente. Driver xDBC di Filemaker, manco a parlarne. Funziona solo il driver di Actual. E benino, debbo ammettere. Le password te le chiede una sola volta, se le ricorda, ti fa vedere quello che chiedi, abbastanza velocemente (ma, forse, è dovuto al limite della demo: 3 righe per tabella).

FileMaker Pro 13 Adv: sempre per la serie «proviamole tutte, anche se non ci credo». Alla prima: driver MySQL open source (da mysql.com) a 32 bit funziona. Lento come… qual è la cosa che vi viene in mente pensando a qualcosa di lento? Ecco, quello, ma più lento. Immagino, Giulio Villani, ti riferissi a questo quando decantavi ”stabilità” e ”performance” dei su detti driver.

Ne proverò altre per, ovviamente, arrivare a comprare la licenza Actual. Ma almeno ora so che quando non funzionava non era colpa mia. Son soddisfazioni!

grazie mille

Scusate se replico per la terza volta, ma sono arrivato ad un mezzo successo. Ho provato ad installare il connector a 32bit (per la serie: «tanto non funziona, giusto per provarle tutte-tutte-tutte…»). In iODBC Data Source Administrator il test ha esito positivo. Almeno così dice la finestra che compare.

Quando, però, lo richiamo da FileMaker – schermata ”Relazioni” – mi (ri)chiede nome utente e password (che li metta prima nella finestra ”Modifica origine dati” oppure no), ma non li accetta. Li inserisco, confermo e lui li cancella. A tal proposito, non divrei vedere il database nelle Tabelle?

Aggiungo alcuni tentativi fatti, magari anticipo qualche vostro dubbio.

Da Terminale:

lipo -info /usr/local/lib/libmyodbc5a.so
Non-fat file: /usr/local/lib/libmyodbc5a.so is architecture: x86_64

lipo -info /usr/local/lib/libmyodbc5w.so
Non-fat file: /usr/local/lib/libmyodbc5w.so is architecture: x86_64

lipo -info /Applications/ [omissis] /iODBC Administrator
Non-fat file: /Applications/ [omissis] /iODBC Administrator is architecture: i386

lipo -info /Applications/ [omissis] /FileMaker Pro
Architectures in the fat file: /Applications/ [omissis] /FileMaker Pro are: x86_64 i386

In iODBC Data Source Administrator mi dà:

1) IM003

[iODBC] [Driver Manager] Specified driver could not be loaded

2) 00000

[iODBC] [Driver Manager] dlopen (/usr/local/lib/libmyodbc5w.so, 6): no suitable image found. Did find: /usr/local/lib/libmyodbc5w.so: mach-o, but wrong architecture

Sul file odbc.ini ho aggiunto:

[myodbc_prova]
Driver = /usr/local/lib/libmyodbc5w.so
DATABASE = nome_db
PWD = password
SERVER = 12.34.56.78
PORT = 3306
UID = nome_utente

Sul file odbcinst.ini:

[MySQL ODBC 5.1 Driver]
Driver      = /usr/local/lib/libmyodbc5w.so

Ho anche provato, invece di libmyodbc5w.so, ad usare libmyodbc5a.so (non so qual è la differenza, ambedue sono a 64bit…), ma, comunque, l’unica differenza è che mi dà lo stesso errore, ma, ovviamente, sul connettore scelto.

Grazie mille,

la strada da percorrere, lasciando momentaneamente da parte i driver Actual (che ho provato ad installare e, pare, mostrano e ”ricordano” tutto correttamente), pensi possa essere la modifica del file odbc.ini?

In realtà ho provato ad aggiungere i dati di accesso ad un database (al quale riesco a collegarmi con Sequel Pro, un applicativo di gestione MySql) remoto conosciuto sul file odbc.ini, ma continua a richiedermeli (e non accettarli) nonostante siano corretti [sic!]. Farò qualche prova, un ultimo dubbio: le keyword all’interno del file odbc.ini hanno specifiche particolari? Ad esempio: key sensitive, ordine specifico, pre-dichiarazione manuale nel driver?

grazie

Buongiorno, Haring.

in teoria, hai fatto tutto bene. Nella mia esperienza i driver mysql per mac non brillano ne per stabilità né per performance. Il mio consiglio è usa actual e vivi felice. In alternativa, temo tu debba andare per tentativi

.g.