Discussione:
Qual è l'equivalente di Access per Mac?
(troppo vecchio per rispondere)
Mac dal 1993
2004-12-14 12:03:22 UTC
Permalink
Che ne dite?

Ho visto che l'ultima versione di Filmaker è potente, ma è all'altezza di un
Access?

Alternative?

Quanto costano?

Byebye

--------------------------------
Inviato via http://arianna.libero.it/usenet/
Enrico Gregorio
2004-12-14 12:27:18 UTC
Permalink
Post by Mac dal 1993
Che ne dite?
Ho visto che l'ultima versione di Filmaker è potente, ma è all'altezza di un
Access?
Alternative?
Quanto costano?
Non conosco Access, ma ho usato, ahimé, programmi prodotti
in tale ambiente di programmazione (?).

Per fortuna non esistono analoghi sistemi nel mondo Mac.

A proposito di Access: dovrebbe essere pronunciato "Aksèss"
ma moltissimi usano pronunciare "Àccess" (con la doppia "c").
Che sia perché ricorda un locale che si trova in molte case?

Ciao
Enrico
Mac dal 1993
2004-12-14 12:37:36 UTC
Permalink
Post by Enrico Gregorio
Non conosco Access, ma ho usato, ahimé, programmi prodotti
in tale ambiente di programmazione (?).
Per fortuna non esistono analoghi sistemi nel mondo Mac.
Per fortuna lo dici tu! Perché credi che abbia scritto questo messaggio se
avessi già visto qualcosa anche solo di vagamente simile per il Mac?
Il fatto di essere (orgogliosamente) utenti Mac non ci deve far calare un
velo sugli occhi e riconoscere che su questo fronte siamo carenti.
Uso Access in ufficio e ti assicuro che è un programma tra i più complessi e
articolati tra quelli messi di default.
A proposito, Access è inserito nell'Office di Window, mentre il Mac ti mette
al massimo un Outlook rinominandolo Entourage che fa più fine.
Post by Enrico Gregorio
A proposito di Access: dovrebbe essere pronunciato "Aksèss"
ma moltissimi usano pronunciare "Àccess" (con la doppia "c").
Che sia perché ricorda un locale che si trova in molte case?
Un commento veramente gratuito!
La pronuncia? Un problema tipicamente italiano, dove ogni minima parola
straniera crea scompensi psicologici non da poco. Vogliamo parlare di come
sento pronunciare Excel? Lasciamo perdere, ho appena mangiato!



Essere parte di un gruppo (Apple lovers), non vuol dire buttare fango su
tutto quello che gruppo non è. Troppo facile: non richiede neanche lo sforzo
di analizzare criticamente!


Bye bye

--------------------------------
Inviato via http://arianna.libero.it/usenet/
SAP
2004-12-14 13:49:13 UTC
Permalink
Post by Mac dal 1993
Per fortuna lo dici tu! Perché credi che abbia scritto questo messaggio se
avessi già visto qualcosa anche solo di vagamente simile per il Mac?
Access e' un TROIAIO.

Ci sono una valanga di software migliori sotto tutti i punti di vista.
La sua popolarita' si deve al fatto che Office Professional e' uno dei
pacchetti piu' piratati della storia.
Post by Mac dal 1993
Uso Access in ufficio e ti assicuro che è un programma tra i più complessi e
articolati tra quelli messi di default.
Complessi e articolati, bravo.
Le stesse cose che fai su Access le fai in FIleMaker nella meta' del
tempo.
COMPLESSO non e' obbligatoriamente un pregio sai.
Post by Mac dal 1993
A proposito, Access è inserito nell'Office di Window, mentre il Mac ti mette
al massimo un Outlook rinominandolo Entourage che fa più fine.
Office Professional.
Che costa.
Prova un po' a guardare quanto costa e poi ne riparliamo.
Che poi il software si possa copiare e' un altroppaio di maniche.
Cosa cavolo c'etra poi Entourage lo sai solo te, dato che e' un client
di posta elettronica.

Io ringrazio ogni giorno la Mac Unit di Redmond che mi ha graziato da un
software scritto con i piedi come Access.
--
Giocare col mondo, facendolo a pezzi...
Bambini che il sole, ha ridotto gia'... vecchi.
Daniele Purrone
2004-12-14 14:07:29 UTC
Permalink
Post by SAP
Io ringrazio ogni giorno la Mac Unit di Redmond che mi ha graziato da un
software scritto con i piedi come Access.
Non è che lo hanno fatto per farti un favore, è che non possono portarlo
:-D

Daniele
--
"I'm just a Soldier of Fortune,
Must be the Gypsy in me!" (Coverdale)

STARGAZER: www.stargazer.it - Le stelle della scena Hard & Heavy!
SAP
2004-12-14 14:19:07 UTC
Permalink
Post by Daniele Purrone
Non è che lo hanno fatto per farti un favore, è che non possono portarlo
Non mettere limiti al Male.
Possono fare di tutto, anche quello.

Prega con me fratello, che le forze del Male siano ricacciate nel buio
in aeterno.
--
Giocare col mondo, facendolo a pezzi...
Bambini che il sole, ha ridotto gia'... vecchi.
gomi no sensei
2004-12-14 16:20:50 UTC
Permalink
Post by SAP
Non mettere limiti al Male.
Possono fare di tutto, anche quello.
mi tocco
--
e io contavo i denti ai francobolli
Mac dal 1993
2004-12-14 18:22:55 UTC
Permalink
Post by SAP
Access e' un TROIAIO.
Non credo, solo che bisogna buttarsi un po' di impegno e i risultati escono
Post by SAP
Ci sono una valanga di software migliori sotto tutti i punti di vista.
Quali? In questo vespaio che senza volere ho tirato su sento solo parlare
del caro vecchio Filemaker (che, figurati, possedevo nel 1994 ancora su
floppy........ Il 7 l'ho visto solo sul sito) e 4D, la vera new entry nelle
mie conoscenze e che indagherò.
Post by SAP
La sua popolarita' si deve al fatto che Office Professional e' uno dei
pacchetti piu' piratati della storia.
Intendi crackati, scopiazzati? Mal comune...
Post by SAP
Post by Mac dal 1993
Uso Access in ufficio e ti assicuro che è un programma tra i più complessi e
articolati tra quelli messi di default.
Complessi e articolati, bravo.
Le stesse cose che fai su Access le fai in FIleMaker nella meta' del
tempo.
E' proprio questo che volevo sapere! Parli della versione 7? Se leggi tutti
i post, altri apprezzano di più 4D
Post by SAP
Cosa cavolo c'etra poi Entourage lo sai solo te, dato che e' un client
di posta elettronica.
Per dire che riempono l'office base così
Post by SAP
Io ringrazio ogni giorno la Mac Unit di Redmond che mi ha graziato da un
software scritto con i piedi come Access.
Io ringrazio di avere a casa un Mac, ma ciò non mi impedisce di apprezzare
anche qualcosa di ciò che sta fuori dal mio orticello.

--------------------------------
Inviato via http://arianna.libero.it/usenet/
fbrzvnrnd
2004-12-14 18:48:09 UTC
Permalink
Post by Mac dal 1993
Quali? In questo vespaio che senza volere ho tirato su sento solo parlare
del caro vecchio Filemaker (che, figurati, possedevo nel 1994 ancora su
ripeto: neooffice+mysql



f.
--
avete mai assaggiato le lame rotanti? http://www.lamerotanti.com
Joebuzz
2004-12-14 20:34:24 UTC
Permalink
Post by fbrzvnrnd
ripeto: neooffice+mysql
Con quale driver ti connetti? Io con connector/j non ci riesco...

Ciao

Pippo
fbrzvnrnd
2004-12-14 21:10:34 UTC
Permalink
Post by Joebuzz
Post by fbrzvnrnd
ripeto: neooffice+mysql
Con quale driver ti connetti? Io con connector/j non ci riesco...
io ci sono riuscito solo con quello (con myodbc mi dava i database in
sola lettura).


f.
--
avete mai assaggiato le lame rotanti? http://www.lamerotanti.com
SAP
2004-12-14 21:14:13 UTC
Permalink
fbrzvnrnd
Post by fbrzvnrnd
io ci sono riuscito solo con quello (con myodbc mi dava i database in
sola lettura).
Ma hai provato anche CocoaMySQL o YourSQL?
A me piace sopratutto il secondo e li trovo molto agili e snelli per
lavorare su MySQL.
--
Giocare col mondo, facendolo a pezzi...
Bambini che il sole, ha ridotto gia'... vecchi.
fbrzvnrnd
2004-12-14 21:20:23 UTC
Permalink
Post by SAP
Ma hai provato anche CocoaMySQL o YourSQL?
A me piace sopratutto il secondo e li trovo molto agili e snelli per
lavorare su MySQL.
i database li devo creare con cocoamysql, ma poi li gestisco con
neooffice. Con form, pulsantini e report vari.



f.
--
avete mai assaggiato le lame rotanti? http://www.lamerotanti.com
Giovanni Mannarino
2004-12-14 21:22:59 UTC
Permalink
fbrzvnrnd
Post by fbrzvnrnd
ripeto: neooffice+mysql
Curiosità mia: NeoOffice ha anche un frontend da GUI (si, insomma, un
menu, bottone o altri cazzilli) per esportare i database oppure ti
affidi a PHPMyAdmin o altri programmi?

TIA Giovanni
fbrzvnrnd
2004-12-14 21:45:30 UTC
Permalink
Post by Giovanni Mannarino
Curiosità mia: NeoOffice ha anche un frontend da GUI (si, insomma, un
menu, bottone o altri cazzilli) per esportare i database oppure ti
affidi a PHPMyAdmin o altri programmi?
al momento è ancora in fase di testaggio, non ho mai fatto prove di
backup. Direi che -così a prima vista- non ce ne sono.



f.
--
avete mai assaggiato le lame rotanti? http://www.lamerotanti.com
Giovanni Mannarino
2004-12-14 22:31:05 UTC
Permalink
fbrzvnrnd
Post by fbrzvnrnd
al momento è ancora in fase di testaggio, non ho mai fatto prove di
backup.
Non è solo un backup, il file che viene creato dovrebbe essere visibile
da tutti gli altri database MySQL di versione compatibile su qualunque
piattaforma, il che rende la cosa interessante.
Post by fbrzvnrnd
Direi che -così a prima vista- non ce ne sono.
Peccato, comunque alternative non mancano per fare un dump dei database.
fbrzvnrnd
2004-12-15 07:59:33 UTC
Permalink
Post by Giovanni Mannarino
Non è solo un backup, il file che viene creato dovrebbe essere visibile
da tutti gli altri database MySQL di versione compatibile su qualunque
piattaforma, il che rende la cosa interessante.
al momento la mia conoscenza di mysql è pari a zero zero. il mio
interesse è solo focalizzato ad avere un database relazionale
utilizzabile da neooffice per provare a trasferire una parte del mio
lavoro da spreadsheet a database. più per cultura generale che per altro.



f.
--
avete mai assaggiato le lame rotanti? http://www.lamerotanti.com
Riccardo Saettone
2004-12-15 12:02:15 UTC
Permalink
Post by Mac dal 1993
Post by SAP
Access e' un TROIAIO.
Non credo, solo che bisogna buttarsi un po' di impegno e i risultati escono
Personalmente non ritengo che access a livello di programmazione faccia
schifo, permette di fare rapidamente un sacco di cose anche non
semplicissime.
I problemi avvengono quando lo devono usare gli utenti, il data base di
Access sembra fatto di cristallo tanto e fragile, basta poco per avere i
propri dati distrutti senza possibilita` di recupero.
Post by Mac dal 1993
Post by SAP
Ci sono una valanga di software migliori sotto tutti i punti di vista.
Quali? In questo vespaio che senza volere ho tirato su sento solo parlare
del caro vecchio Filemaker (che, figurati, possedevo nel 1994 ancora su
floppy........ Il 7 l'ho visto solo sul sito) e 4D, la vera new entry nelle
mie conoscenze e che indagherò.
Non disprezzare tanto Filmaker a livello di potenza da le stesse cose di
access, ed in alcuni campi anche di piu`, vedi il web.
A livello di programmazione puo` piacere o non piacere, a me personalemnte
non piace piu` di tanto, sopratutto quando le applicazioni diventano molto
grosse e bisogna modificare applicazioni gia` fatte.
Filemaker ha anche il grosso vantaggio di costare poco, anche se ultimanente
i costi sono un po` lievitati.

Come gia` detto ti consiglio di provare 4D lo sto studiando anche io in
questo periodo, e mi sta intrigando un sacco.
--
Riccardo Saettone
Per rispondere togliere Alfa e Beta dall'indirizzo
SAP
2004-12-15 12:17:39 UTC
Permalink
Post by Riccardo Saettone
I problemi avvengono quando lo devono usare gli utenti, il data base di
Access sembra fatto di cristallo tanto e fragile, basta poco per avere i
propri dati distrutti senza possibilita` di recupero.
Mi mancava questa perla.

E pensare che questo della corruzione dei files e' uno dei difetti che
ogni tanto imputo a FMP...
--
Giocare col mondo, facendolo a pezzi...
Bambini che il sole, ha ridotto gia'... vecchi.
Riccardo Saettone
2004-12-15 12:26:33 UTC
Permalink
Post by SAP
Post by Riccardo Saettone
I problemi avvengono quando lo devono usare gli utenti, il data base di
Access sembra fatto di cristallo tanto e fragile, basta poco per avere i
propri dati distrutti senza possibilita` di recupero.
Mi mancava questa perla.
E pensare che questo della corruzione dei files e' uno dei difetti che
ogni tanto imputo a FMP...
Io ovviamente parlo solo riaguardo alla mia sperienza personale e devo dire
che statisticamente i file di databse di access si corrompono piu` spesso
che non quelli di FileMaker.
E parlo di applicazioni comprate e che sono costate diversi soldi.
--
Riccardo Saettone
Per rispondere togliere Alfa e Beta dall'indirizzo
SAP
2004-12-15 12:17:40 UTC
Permalink
Post by Riccardo Saettone
Come gia` detto ti consiglio di provare 4D lo sto studiando anche io in
questo periodo, e mi sta intrigando un sacco.
Bel prodotto davvero, se proprio devo trovargli un difetto e' la sua
scarsissima diffusione il che rende difficile trovare supporto in altri
utenti, forum di discussione e altro.
Insomma, e' molto raro trovare altri utilizzatori coi quali
confrontarsi...
--
Giocare col mondo, facendolo a pezzi...
Bambini che il sole, ha ridotto gia'... vecchi.
Riccardo Saettone
2004-12-15 12:28:56 UTC
Permalink
Post by SAP
Bel prodotto davvero, se proprio devo trovargli un difetto e' la sua
scarsissima diffusione il che rende difficile trovare supporto in altri
utenti, forum di discussione e altro.
Insomma, e' molto raro trovare altri utilizzatori coi quali
confrontarsi...
SAP tu lo usi normalmente ?
Io sto valutando appunto se abbandonare Access e Filemaker per passare a 4D.
Quello che vorrei capire e` se e` possibile importare detta tabello di acees
e filmaker complete di relazioni in 4D ?
--
Riccardo Saettone
Per rispondere togliere Alfa e Beta dall'indirizzo
SAP
2004-12-15 13:50:51 UTC
Permalink
Post by Riccardo Saettone
SAP tu lo usi normalmente ?
L'ho provato e in passato ne sono stato utilizzatore, ora e' un po' che
penso di riprenderlo, ma e' passato un po' troppo tempo.
Post by Riccardo Saettone
Io sto valutando appunto se abbandonare Access e Filemaker per passare a 4D.
Quello che vorrei capire e` se e` possibile importare detta tabello di acees
e filmaker complete di relazioni in 4D ?
La vedo un po' complicata, comunque, sulla documentazione e sul sito si
dice nulla a riguardo?
--
Giocare col mondo, facendolo a pezzi...
Bambini che il sole, ha ridotto gia'... vecchi.
Riccardo Saettone
2004-12-18 14:40:46 UTC
Permalink
Post by SAP
Post by Riccardo Saettone
Io sto valutando appunto se abbandonare Access e Filemaker per passare a 4D.
Quello che vorrei capire e` se e` possibile importare detta tabello di acees
e filmaker complete di relazioni in 4D ?
La vedo un po' complicata, comunque, sulla documentazione e sul sito si
dice nulla a riguardo?
Ci ho dato una occhiata veloce ma non ho trovato nulla, lunedi prvo con piu`
calma.
Il mio principale problema e che o un sacco di tabelle con relezioni e quindi
per me sarebbe un grande vantaggio poter imporatare almeno quelle.

In questi giorni ho continuato avedere 4D e devo dire che mi sat piacendo un
sacco, in pratica ha la versatilita` di programmazione che a Access, ma anche
un sacco delle agevolazioni che ho visto in filemaker.
Ora bisogna vedere se riesco a convincere i miei capi.

Certo e che cosi potrei avere tutto centralizzato invece che la miriade di
applicazioni spezzettate che abbiamo ora.
--
Riccardo Saettone
Per rispondere togliere Alfa e Beta dall'indirizzo
SAP
2004-12-19 23:10:48 UTC
Permalink
Post by Riccardo Saettone
Ci ho dato una occhiata veloce ma non ho trovato nulla, lunedi prvo con piu`
calma.
Il mio principale problema e che o un sacco di tabelle con relezioni e quindi
per me sarebbe un grande vantaggio poter imporatare almeno quelle.
Ora non ho modo di sapere se si puo' portare in modo piu' o meno
indolore tutto l'ambaradan in 4D da FMP.
Varrebbe la pena al limite in vista di un possibile switch chiedere
direttamente al loro supporto.
Post by Riccardo Saettone
In questi giorni ho continuato avedere 4D e devo dire che mi sat piacendo un
sacco, in pratica ha la versatilita` di programmazione che a Access, ma anche
un sacco delle agevolazioni che ho visto in filemaker.
Gia', l'ultima versione che ho guardato con un minimo di attenzione (la
6.7 credo) era gia' molto migliorata a livello utente, immagino siano
andati avanti abbastanza...
--
Giocare col mondo, facendolo a pezzi...
Bambini che il sole, ha ridotto gia'... vecchi.
Angelfall
2004-12-14 20:51:07 UTC
Permalink
Post by SAP
Le stesse cose che fai su Access le fai in FIleMaker nella meta' del
tempo.
Mi spiace, ma questo e' falso: Filemaker insiste a *non* fare una serie
di cose che ti aspetti da qualsiasi altro DBMS.
Per non parlare del fatto che piu' va avanti e piu' si chiude verso
l'esterno.
--
Quando c'era lui i treni partivano in orario
Quando c'era lui ci deportavano in orario
SAP
2004-12-14 20:58:55 UTC
Permalink
Post by Angelfall
Mi spiace, ma questo e' falso: Filemaker insiste a *non* fare una serie
di cose che ti aspetti da qualsiasi altro DBMS.
Mah, fammi qualche esempio.

Io ricordo quando ho aperto per la prima volta FileMaker, dopo 5 minuti
gia' facevo relazioni, maschere e sono stato immediatamente produttivo.
Con Access e' stato un odio a pelle, non l'ho mai sopportato, ho sempre
detestato il suo modo di impostare le query, mi e' sempre sembrato un
vorrei ma non posso.

Piuttosto mille volte 4D.
--
Giocare col mondo, facendolo a pezzi...
Bambini che il sole, ha ridotto gia'... vecchi.
Angelfall
2004-12-15 07:51:37 UTC
Permalink
Post by SAP
Post by Angelfall
Mi spiace, ma questo e' falso: Filemaker insiste a *non* fare una serie
di cose che ti aspetti da qualsiasi altro DBMS.
Mah, fammi qualche esempio.
Impossibilita' (*ancora* oggi con la versione 7) di esprimere una query
in SQL da cui discendono:
- Left join e right join inesistenti
- impossibile (almeno fino alla 7, ma anche con questa non va troppo
bene) esprimere correttamente certe relazioni un po' piu' complesse
Supporto verso ODBC scarso e fatto male.
Non si possono collegare tabelle esterne in maniera dinamica.
Nelle funzionalita' di scripting manca totalmente la possibilita' di
interfacciarsi con il filesystem, sia di effettuare un browsing di una
cartella che di aprire un file di testo e leggerci/scriverci dentro.
Il motore di query e' *parecchio* piu' lento di quello di Access, sia in
ricerca che in indicizzazione.
Per descrivere una AND logica in una interrogazione devi fare degli
equilibrismi.
Per utilizzarlo, su Windows, tramite ODBC devi tenere il programma
aperto (!).
L'interfaccia per effettuare le query in FM e' una genialata, ma devi
fare le cose come dice lui o nulla, anche qui l'impossibilita' di usare
SQL e' limitante.
Con la 7 (ma ne avevamo gia' parlato) hanno raggiunto un apice di
incompatibilita' con se' stessi che manco microsoft nei suoi momenti
peggiori.

Basta, mi so' stufato ;-)
Post by SAP
Io ricordo quando ho aperto per la prima volta FileMaker, dopo 5 minuti
gia' facevo relazioni, maschere e sono stato immediatamente produttivo.
Ed e' esattamente a quello che serve un prodotto come FM: questa tua
frase lo descrive alla perfezione. Se cerchi di farci qualcosa in piu'
stai pronto a dare dolorose capocciate contro il muro.
Post by SAP
Con Access e' stato un odio a pelle, non l'ho mai sopportato, ho sempre
detestato il suo modo di impostare le query, mi e' sempre sembrato un
vorrei ma non posso.
Il modello di query di Access e'... il modo in cui un client DBMS SQL
*deve* fare le query. Se dai uno sguardo a prodotti consimili ritroverai
il QBE e la possibilita' di utilizzare SQL.
Non e' un vorrei ma non posso, anzi, probabilmente e' il prodotto
microsoft che si e' piu' concentrato sulla funzionalita' complessiva,
piuttosto che sulle trovate cosmetiche.
--
Quando c'era lui i treni partivano in orario
Quando c'era lui ci deportavano in orario
SAP
2004-12-15 11:07:59 UTC
Permalink
Post by Angelfall
Post by SAP
Mah, fammi qualche esempio.
Impossibilita' (*ancora* oggi con la versione 7) di esprimere una query
Ma FileMaker NON e' un DB SQL.
E' nato come DB flat e solo dalla V. 3 hanno implementato (maluccio) un
minimo di relazionalita'.

Ma a me va' bene cosi': ne conosco i limiti e lo apprezzo comunque.
Ne apprezzo sopratutto la semplicita' di utilizzo e l'immediata
produttivita'.

Se uno vuole un DB che sia compatibile con SQL e abbastanza semplice,
gli consiglio fra i prodotti commerciali 4D.
Post by Angelfall
- Left join e right join inesistenti
- impossibile (almeno fino alla 7, ma anche con questa non va troppo
bene) esprimere correttamente certe relazioni un po' piu' complesse
Supporto verso ODBC scarso e fatto male.
Vedi sopra: non stiamo parlando di un db SQL.
Post by Angelfall
Non si possono collegare tabelle esterne in maniera dinamica.
Questa non l'ho capita.
Post by Angelfall
Nelle funzionalita' di scripting manca totalmente la possibilita' di
interfacciarsi con il filesystem, sia di effettuare un browsing di una
cartella che di aprire un file di testo e leggerci/scriverci dentro.
Non mi risulta proprio.
Anzi la scrittura su file esterni di appoggio e' supportata fin dalla
versione 3.
Post by Angelfall
Il motore di query e' *parecchio* piu' lento di quello di Access, sia in
ricerca che in indicizzazione.
Troppo lento, e' un problema strutturale di FMP.
Lo si sente sopratutto se si usa FMP come DB per web e li' e' una croce,
ma per usi personali sul proprio PC non si nota, in caso di rete locale
invece il server di FMP integra un motore molto piu' veloce.
Post by Angelfall
Per descrivere una AND logica in una interrogazione devi fare degli
equilibrismi.
Per utilizzarlo, su Windows, tramite ODBC devi tenere il programma
aperto (!).
Lo devi tenere aperto SEMPRE in TUTTI i casi nei quali tu voglia
raggiungere quei dati, dato che l'host del DB e' l'applicazione, non
qualche strato software piu' o meno integrato nel sistema.
Altrimenti prendi il server che gira come servizio e non ha questa
limitazione.
E' cosi' da SEMPRE, personalmente non lo ritengo neanche un limite, dato
che se ho bisogno di un accesso ODBC ai dati di solito e' per altri
motivi e mi rivolgo ad altri DB REALMENTE SQL compliant come MySQL,
Postgres ecc.

Quello che non capisco e' perche' la gente si ostina ad usare Access
come una via di mezzo tra un vero DB SQL e un RDBMS visuale, producendo
ibridazioni orribili che finiscono per diventare standard per essendo
soluzioni proprietarie come la pessima abitudine di usare access per il
web con robe fatte con frontpage e asp.
Capisco la comodita' inserire un file di access nell'inetpub e vederlo
interrogare come fosse gia' aperto, ma e' anche grazie a queste cose che
il web pullula di siti scritti coi piedi, di linguaggi di scripting
proprietari che abbisognano per forza di sistemi windows, di
vulnerabilita' piu' o meno latenti sempre piu' diffuse.
Post by Angelfall
L'interfaccia per effettuare le query in FM e' una genialata, ma devi
fare le cose come dice lui o nulla, anche qui l'impossibilita' di usare
SQL e' limitante.
Again: FMP non e' un DB SQL, basta saperlo e usralo per quello che ti
da'.
Post by Angelfall
Con la 7 (ma ne avevamo gia' parlato) hanno raggiunto un apice di
incompatibilita' con se' stessi che manco microsoft nei suoi momenti
peggiori.
La 7 non la conosco bene e mi sta' gia' sul cazzo per essersi
"accessizzata" con la storia dei DB multitabellari, pensa un po' :-D
Post by Angelfall
Non e' un vorrei ma non posso, anzi, probabilmente e' il prodotto
microsoft che si e' piu' concentrato sulla funzionalita' complessiva,
piuttosto che sulle trovate cosmetiche.
Una domanda che puo' suonare provocatoria ma non lo e': ma MS-SQL cosa
ci sta' a fare se Access funziona cosi' bene?
Cioe': il DB VERAMENTE SQL compliant la MS ce l'ha gia' ed e' un ciccino
piu' potente e completo di Access.
--
Giocare col mondo, facendolo a pezzi...
Bambini che il sole, ha ridotto gia'... vecchi.
Alex Martelli
2004-12-15 13:45:15 UTC
Permalink
Post by SAP
Post by Angelfall
Non e' un vorrei ma non posso, anzi, probabilmente e' il prodotto
microsoft che si e' piu' concentrato sulla funzionalita' complessiva,
piuttosto che sulle trovate cosmetiche.
Una domanda che puo' suonare provocatoria ma non lo e': ma MS-SQL cosa
ci sta' a fare se Access funziona cosi' bene?
Cioe': il DB VERAMENTE SQL compliant la MS ce l'ha gia' ed e' un ciccino
piu' potente e completo di Access.
Access serve rigorosamente soltanto a fare i front-end. Come back-end
puo` usare Jet (spesso erroneamente noto come "il DB di Access") ma
anche MS-SQL o Oracle o quant'altro. Jet e` liberamente scaricabile (ma
non sono sorgenti, e girano solo su Windows) e ridistribuibile. Ma se
e` per questo lo e` anche MSDE, il Microsoft Data Engine, che e` un
back-end molto migliore (praticamente MS-SQL, senza GUI o che altro e
limitato a 5 utenze simultanee, comunque molto migliore di Jet).

L'architettura a Front-end / Back-end e` ovviamente una buona idea. Il
Back-end (Jet) e` ovviamente una ciofeca, e la prima a dirlo e` MS, che
infatti da anni ormai consiglia di usare invece MSDE (per app. piccole;
oltre le 5 utenze simultanee, consiglia MS-SQL, ovviamente;-). Il
Front-end in quanto tale, cioe` Access appunto, boh, c'e` di peggio,
c'e` sicuramente anche di meglio, ma alla fin fine non lo conosco
abbastanza da darne un giudizio preciso (i back-end li conosco bene, ma
li ho sempre usati scrivendo varie forme di front-end con svariati
linguaggi e librerie, non con front-end + o - precotti, quindi sono piu`
scarso d'esperienza relativamente a questi ultimi).


Alex
Angelfall
2004-12-15 20:51:15 UTC
Permalink
Post by SAP
Post by Angelfall
Post by SAP
Mah, fammi qualche esempio.
Impossibilita' (*ancora* oggi con la versione 7) di esprimere una query
Ma FileMaker NON e' un DB SQL.
E neanche Access lo e': SQL sta per System Query Language, e' un
*linguaggio* di query, con la struttura relazionale c'entra nulla.
Infatti ho detto che Access ha la *possibilita'* di esprimere delle
query in SQL e questo ti apre un mondo che con FM ti e' precluso, quello
di dialogare con basi di dati gestite da altri sistemi (Oracle
anybody?). FM segue una struttura logica talmente proprietaria che gli
impedisce di creare determinate relazioni che sono la normalita' in
qualsiasi altro sistema e non lo sono per moda, ma per necessita'. Una
left join, per riportarci ad un esempio di poco fa, ti risolve un
problema altrimenti irrisolvibile con FM, e questo non e' bello.
Post by SAP
E' nato come DB flat e solo dalla V. 3 hanno implementato (maluccio) un
minimo di relazionalita'.
vedi sopra.
Post by SAP
Se uno vuole un DB che sia compatibile con SQL e abbastanza semplice,
gli consiglio fra i prodotti commerciali 4D.
Ma non stiamo discutendo di questo, ma del fatto che Access sia una
schifezza immonda e FM una figata galattica: puo' essere vero finche' ci
fai cose semplici, la faccenda si ribalta completamente quando la
faccenda si fa complessa.
Post by SAP
Post by Angelfall
- Left join e right join inesistenti
- impossibile (almeno fino alla 7, ma anche con questa non va troppo
bene) esprimere correttamente certe relazioni un po' piu' complesse
Supporto verso ODBC scarso e fatto male.
Vedi sopra: non stiamo parlando di un db SQL.
Ma stiamo parlando di un db: sai cosa fa un right join? Permette di
visualizzare *tutti* i record della tabella A e aggiungere, solo nel
caso che venga soddisfatta la condizione di relazione, i dati della
tabella B. Beh, questa cosa semplice in FM *non* *si* *puo'* *fare*.
Questo non e' SQL, e' semplicemente una funzionalita' relazionale, che
se fai un db che si dice relazionale (ed il marketing di FM lo proclama
a gran voce) lo devi poter fare.
Post by SAP
Post by Angelfall
Non si possono collegare tabelle esterne in maniera dinamica.
Questa non l'ho capita.
Mmmmmh, facciamo un esempio: ho due-tre tabelle sul mio pc che pero'
hanno bisogno di relazionarsi con una tabella (o meglio: una vista
logica) che risiede su altro DBMS. Con Access, posto di possedere il
driver ODBC giusto, dichiaro la tabella nel mio db locale e la uso, che
venga da Oracle, da MS-SQL, da altro pc, da Excel, da file di testo, qui
o attraverso internet poco importa; con FM non posso collegare *nulla*
se non altre tabelle FM e solo dalla mia rete locale.
Post by SAP
Post by Angelfall
Nelle funzionalita' di scripting manca totalmente la possibilita' di
interfacciarsi con il filesystem, sia di effettuare un browsing di una
cartella che di aprire un file di testo e leggerci/scriverci dentro.
Non mi risulta proprio.
Anzi la scrittura su file esterni di appoggio e' supportata fin dalla
versione 3.
Puoi creare/scrivere/aprire un file di testo? E come?
Sicuramente non puoi ottenere una semplicissima lista dei file presenti
in una directory.
Post by SAP
Post by Angelfall
Il motore di query e' *parecchio* piu' lento di quello di Access, sia in
ricerca che in indicizzazione.
Troppo lento, e' un problema strutturale di FMP.
Lo si sente sopratutto se si usa FMP come DB per web e li' e' una croce,
ma per usi personali sul proprio PC non si nota
Prova ad usarlo su dieci-ventimila record e fagli fare un sort con campi
di una tabella collegata e poi ne riparliamo: belle le barre di
progresso, nevvero? ;-)
Post by SAP
, in caso di rete locale
invece il server di FMP integra un motore molto piu' veloce.
Mai provato, troppo caro per l'unica cosa che fa.
Post by SAP
Post by Angelfall
Per descrivere una AND logica in una interrogazione devi fare degli
equilibrismi.
Per utilizzarlo, su Windows, tramite ODBC devi tenere il programma
aperto (!).
Lo devi tenere aperto SEMPRE in TUTTI i casi nei quali tu voglia
raggiungere quei dati, dato che l'host del DB e' l'applicazione, non
qualche strato software piu' o meno integrato nel sistema.
Tutti gli altri scrivono dei driver, non delle applicazioni intere,
semplicemente perche' utilizzano uno standard invece dell'orrido
pastrocchio proprietario che deve tenere aperto tutto l'ambaradan per
rispondere ad interrogazioni tipo SELECT * FROM CLIENTI
Post by SAP
Altrimenti prendi il server che gira come servizio e non ha questa
limitazione.
Peccato che il server FM *non* supporta ODBC, ma serva solo a superare
il limite di dieci client in sharing. Inoltre, ma tu hai provato ad
utilizzare una tabella FM tramite ODBC? Io si': per fargli selezionare
cinquanta record da mille ci ha messo 2 minuti e quindici secondi (!!).
Il client che aspettava la risposta e' andato in timeout(!!).
Post by SAP
E' cosi' da SEMPRE, personalmente non lo ritengo neanche un limite, dato
che se ho bisogno di un accesso ODBC ai dati di solito e' per altri
motivi e mi rivolgo ad altri DB REALMENTE SQL compliant come MySQL,
Postgres ecc.
Quindi se tu becchi un ufficio che utilizza FM da un tot di tempo *e* ha
esigenze di ODBC, gli smonti tutta la struttura db che ha in FM, la
ricrei in MySQL, gli riscrivi tutte le applicazioni che corrispondano a
quello che utilizzavano in FM e gli impedisci di usare quello che hanno
usato fino ad oggi perche' tanto e' cieco come una talpa?
Mah.
Costoso, se non altro.
Post by SAP
Quello che non capisco e' perche' la gente si ostina ad usare Access
come una via di mezzo tra un vero DB SQL e un RDBMS visuale, producendo
ibridazioni orribili che finiscono per diventare standard per essendo
soluzioni proprietarie come la pessima abitudine di usare access per il
web con robe fatte con frontpage e asp.
Come ti spiega un palletto piu' in la' Alex: Access non pretende in
nessun modo di essere il motore DBMS. Quello e' Jet, oppure MSDE, oppure
MS-SQL, oppure (perche' no?) Oracle. Access fa il suo lavoro sullo
strato presentation, non si occupa dei dati. Il contrario in FM, dove
separare la presentazione dai dati e' virtualmente impossibile.
Insomma i dati di una tabella Access sono scalabili verso sistemi piu'
potenti ed interrogabili da applicazioni esterne. La roba di FM se ne
resta dentro a casa sua e non puoi migrarla verso nient'altro.
Post by SAP
Capisco la comodita' inserire un file di access nell'inetpub e vederlo
interrogare come fosse gia' aperto, ma e' anche grazie a queste cose che
il web pullula di siti scritti coi piedi, di linguaggi di scripting
proprietari che abbisognano per forza di sistemi windows, di
vulnerabilita' piu' o meno latenti sempre piu' diffuse.
Senti: la prima vulnerabilita' conclamata di db su web e' un premio
ambito che ha vinto, circa tre anni fa, il buon FileMaker, quando hanno
scoperto che si potevano costruire delle semplici stringhe URL per
cavarne fuori i dati. Non mi risulta che lo stesso possa essere fatto
attraverso ASP. Un database Access viene aperto tramite ODBC o ADO,
supporta vari sistemi di autenticazione (cosa che FM *non* fa in questa
funzione) e non pretende di mettere in piedi un intero motore di server
web per pubblicare i dati (motore, quello si', bucato come pochi), ma
collabora con il server web installato sulla macchina. Inoltre per
l'autenticazione puo' anche appoggiarsi ai servizi di qualche DBMS piu'
evoluto che gestisca metodi piu' avanzati (again MSSQL oppure Oracle).
Hai provato sul serio a mantenere un sito web generato da FM? E pensi
che *quello* sia sicuro??
Post by SAP
Post by Angelfall
L'interfaccia per effettuare le query in FM e' una genialata, ma devi
fare le cose come dice lui o nulla, anche qui l'impossibilita' di usare
SQL e' limitante.
Again: FMP non e' un DB SQL, basta saperlo e usralo per quello che ti
da'.
Again: SQL e' un linguaggio, non una struttura. FM non ti da' troppa
roba per poter essere preso sul serio ad un livello appena piu' alto di
quello personale.
Post by SAP
Post by Angelfall
Con la 7 (ma ne avevamo gia' parlato) hanno raggiunto un apice di
incompatibilita' con se' stessi che manco microsoft nei suoi momenti
peggiori.
La 7 non la conosco bene e mi sta' gia' sul cazzo per essersi
"accessizzata" con la storia dei DB multitabellari, pensa un po' :-D
Ti fa cosi' schifo che *finalmente* se io metto in relazione A con B e B
con C, in una form di A possa vedere i dati di C, senza dover creare
orridi campi calcolati in B? Ma che male ti ha fatto la relazionalita'?
E comunque: la 7 parla solo con la 7 e nient'altro, quindi OsX o niente.
Quindi se hai un tot di licenze 6 le devi upgradare *tutte* a 7. E non
solo i client: upgrada pure tutti i server.
Proprio bravi, davvero.
Post by SAP
Post by Angelfall
Non e' un vorrei ma non posso, anzi, probabilmente e' il prodotto
microsoft che si e' piu' concentrato sulla funzionalita' complessiva,
piuttosto che sulle trovate cosmetiche.
Una domanda che puo' suonare provocatoria ma non lo e': ma MS-SQL cosa
ci sta' a fare se Access funziona cosi' bene?
Stai confrontando un prodotto di un genere con uno di tutt'altro genere.
Ti capisco se vieni da FM in cui, appunto, la presentazione ed i dati
coincidono, ma per tutto il resto della categoria questo non e' vero.
Post by SAP
Cioe': il DB VERAMENTE SQL compliant la MS ce l'ha gia' ed e' un ciccino
piu' potente e completo di Access.
SAP, quest'affermazione non significa veramente nulla.
--
Quando c'era lui i treni partivano in orario
Quando c'era lui ci deportavano in orario
SAP
2004-12-15 22:56:30 UTC
Permalink
Post by Angelfall
Post by SAP
Ma FileMaker NON e' un DB SQL.
E neanche Access lo e': SQL sta per System Query Language, e' un
*linguaggio* di query, con la struttura relazionale c'entra nulla.
Questo lo so' perfettamente, probabilmente e' colpa mia che non riesco a
spiegarmi, ma volevo semplicemente dire che FMP non ha MAI supportato
SQL come linguaggio di query, almeno non in modo pieno e bidirezionale.
Post by Angelfall
Infatti ho detto che Access ha la *possibilita'* di esprimere delle
query in SQL e questo ti apre un mondo che con FM ti e' precluso, quello
di dialogare con basi di dati gestite da altri sistemi (Oracle
anybody?).
Ma in casa mia, per archiviare i CD audio, mi serve la potenza di un
Oracle?
O un Db che supporti SQL?

E comunque, nella versione 6 che ho a disposizione si puo' interagire
con qualunque base dati ODBC supportata da OsX (anche con driver di
terze parti) per eseguire query standard SQL e importare e manipolare
gruppi di dati provenienti dalle piu' disparate fonti.
Se avessi dato un'occhiata alla funzione "esegui SQL" a disposizione
negli script probabilmente non avresti detto il periodo sopra citato.
Con un po' di sforzo si potrebbe usare FMP come front end per
un'estrapolazione mirata di dati da fonti dati molto piu' estese e
complesse.
Post by Angelfall
Ma non stiamo discutendo di questo, ma del fatto che Access sia una
schifezza immonda e FM una figata galattica: puo' essere vero finche' ci
fai cose semplici, la faccenda si ribalta completamente quando la
faccenda si fa complessa.
Ma stavamo parlando di uno che si esalta perche' si trova Access nella
suite di Office e si lamenta perche' Apple non gli da' una roba simile.
A parte il fatto che io non ho mai parlato di figata galattica (lo fai
tu adesso), ho solo stigmatizzato un modo di rappresentare la
strutturazione dei dati di Access che ho sempre trovato astruso e
inutilmente barocco.
Questa mia conoscenza risale ad un paio di versioni fa', non so' come
sia adesso, ma ricordo perfettamente che l'ho odiato fin da subito.
Post by Angelfall
Post by SAP
Vedi sopra: non stiamo parlando di un db SQL.
Ma stiamo parlando di un db: sai cosa fa un right join? Permette di
visualizzare *tutti* i record della tabella A e aggiungere, solo nel
caso che venga soddisfatta la condizione di relazione, i dati della
tabella B. Beh, questa cosa semplice in FM *non* *si* *puo'* *fare*.
Non so' se ho ben capito, se si', la 7 di sicuro lo fa'.
Post by Angelfall
Post by SAP
Post by Angelfall
Non si possono collegare tabelle esterne in maniera dinamica.
Questa non l'ho capita.
Mmmmmh, facciamo un esempio: ho due-tre tabelle sul mio pc che pero'
hanno bisogno di relazionarsi con una tabella (o meglio: una vista
logica) che risiede su altro DBMS. Con Access, posto di possedere il
driver ODBC giusto, dichiaro la tabella nel mio db locale e la uso, che
venga da Oracle, da MS-SQL, da altro pc, da Excel, da file di testo, qui
o attraverso internet poco importa; con FM non posso collegare *nulla*
se non altre tabelle FM e solo dalla mia rete locale.
Ma davvero in uno scenario di piccolissima azienda o studio grafico, o
ambito casalingo hai bisogno di queste cose?
E se e' cosi' potente, perche' quando si fa' davvero sul serio tutti
sono pronti a sparargli addosso dicendo che e' inadeguato?
Post by Angelfall
Post by SAP
Non mi risulta proprio.
Anzi la scrittura su file esterni di appoggio e' supportata fin dalla
versione 3.
Puoi creare/scrivere/aprire un file di testo? E come?
Sicuramente non puoi ottenere una semplicissima lista dei file presenti
in una directory.
FMP si integra ocn AppleScript in modo molto completo, tramite AS puoi
fare quello che vuoi: ottenere listati di directory, manipolarle, creare
files di testo, spostare files, copiarli, cancellarli e sotto OsX
accedere addirittura a tutto l'ambiente Unix.
Non ti pare abbastanza?
Post by Angelfall
Post by SAP
Troppo lento, e' un problema strutturale di FMP.
Lo si sente sopratutto se si usa FMP come DB per web e li' e' una croce,
ma per usi personali sul proprio PC non si nota
Prova ad usarlo su dieci-ventimila record e fagli fare un sort con campi
di una tabella collegata e poi ne riparliamo: belle le barre di
progresso, nevvero? ;-)
Uh?
Ventimila record FMP se li gestisce abbastanza bene se utilizzato con le
giuste ottimizzazioni del caso.
Conosco qualcuno che addirittura (ma io lo sconsiglio) lo usa per
gestire milioni di record (no, giuro, non sto' millantando).
A quel livello certo non si possono maneggiare tutti i record senza
adeguate e importanti ottimizzazioni e limitazioni all'uso utente.
Conosco gente che ha realizzato applicazioni in FMP che seguono in modo
quasi perfetto il modello di separazione dati-struttura, in modo da
poter aggiornare la seconda senza incidere sulla prima, e via dicendo...
Post by Angelfall
Post by SAP
, in caso di rete locale
invece il server di FMP integra un motore molto piu' veloce.
Mai provato, troppo caro per l'unica cosa che fa.
Certo, per essere caro e' caro, ma non e' l'unica cosa che fa', puoi per
esempio schedulare il salvataggio dei files anche quando sono aperti,
incorpora un motore molto piu' potente e veloce, consente la
pubblicazione e distrubuzione dei plug-in di terze parti eventualmente
utilizzati nelle proprie soluzioni, ecc.
Ma insomma, non e' che deve fare poi tantissime cose, e' un sistema di
host dei DB, null'altro.
Post by Angelfall
Post by SAP
Lo devi tenere aperto SEMPRE in TUTTI i casi nei quali tu voglia
raggiungere quei dati, dato che l'host del DB e' l'applicazione, non
qualche strato software piu' o meno integrato nel sistema.
Tutti gli altri scrivono dei driver, non delle applicazioni intere,
semplicemente perche' utilizzano uno standard invece dell'orrido
pastrocchio proprietario che deve tenere aperto tutto l'ambaradan per
rispondere ad interrogazioni tipo SELECT * FROM CLIENTI
Angelfall, i driver di solito si scrivono per applicazioni che girano
come i demoni mysqld, che aprono socket e si comportano come server.
Il pastrocchioproprietario e' certamente proprietario, ma non possiamo
chiamarlo pastrocchio dal momento che e' un modo di lavorare coi dati
semplicemente diverso.
Post by Angelfall
Post by SAP
Altrimenti prendi il server che gira come servizio e non ha questa
limitazione.
Peccato che il server FM *non* supporta ODBC, ma serva solo a superare
il limite di dieci client in sharing. Inoltre, ma tu hai provato ad
utilizzare una tabella FM tramite ODBC? Io si': per fargli selezionare
cinquanta record da mille ci ha messo 2 minuti e quindici secondi (!!).
Il client che aspettava la risposta e' andato in timeout(!!).
Io pensavo che ancora non si potesse fare di interrogarlo in ODBC.
Certo che non e' nato per quello ed e' ovvio che lo facci amalissimo.
Invece le query SQL da FMP verso fonti esterne funzionano abbastanza
bene.
Post by Angelfall
Post by SAP
E' cosi' da SEMPRE, personalmente non lo ritengo neanche un limite, dato
che se ho bisogno di un accesso ODBC ai dati di solito e' per altri
motivi e mi rivolgo ad altri DB REALMENTE SQL compliant come MySQL,
Postgres ecc.
Quindi se tu becchi un ufficio che utilizza FM da un tot di tempo *e* ha
esigenze di ODBC, gli smonti tutta la struttura db che ha in FM, la
ricrei in MySQL, gli riscrivi tutte le applicazioni che corrispondano a
quello che utilizzavano in FM e gli impedisci di usare quello che hanno
usato fino ad oggi perche' tanto e' cieco come una talpa?
Mah.
Costoso, se non altro.
No, in certi casi puo' essere l'unica cosa intelligente che puoi fare
per loro.
Se FMP ha raggiunto i suoi limiti e le richieste sono di una struttura
dati piu' solida che deve reggere un numero di record e transazioni
molto elevato, allora si deve per forza passare a qualcosa di piu'
potente.

Una cosa ancora piu' intelligente potrebbe essere quella di mantenere
FMP come front-end verso applicativi piu' potenti per la gestione dei
dati e spostare i dati stessi da FMP a un diverso DB, affinche' il modo
di lavorare abituale del cliente possa cambiare in minima parte e dia
l'impressione che non si sia modificato troppo.
Post by Angelfall
Post by SAP
Quello che non capisco e' perche' la gente si ostina ad usare Access
come una via di mezzo tra un vero DB SQL e un RDBMS visuale, producendo
ibridazioni orribili che finiscono per diventare standard per essendo
soluzioni proprietarie come la pessima abitudine di usare access per il
web con robe fatte con frontpage e asp.
Come ti spiega un palletto piu' in la' Alex: Access non pretende in
nessun modo di essere il motore DBMS. Quello e' Jet, oppure MSDE, oppure
MS-SQL, oppure (perche' no?) Oracle. Access fa il suo lavoro sullo
strato presentation, non si occupa dei dati. Il contrario in FM, dove
separare la presentazione dai dati e' virtualmente impossibile.
E invece si.
E' possibile farlo e ci sono degli esempi REALI.
Se fossei stato al DevCon, la conferenza degli sviluppatori italiani di
FMP tenutasi quest'anno per la prima volta a Firenze, ti saresti basito
piu' piu' volte (come ha fatto del resto il sottoscritto), nel vedere
quanto l'ingegno possa sopperire a talune effettive mancanze.

Certo, esistono limitazioni ad una netta separazione tra i dati e la
struttura e FMP non aiuta affatto, ma si puo' utilizzando gli strumenti
messi a disposizione a far si che i dati risiedano solo in alcuni files
e che non vengano affatto toccati, che cioe' siano meri vuoti
contenitori, senza script, senza comandi, campi calcolati o altro, in
modo tale da concentrare tutte le funzioni dell'applicazione in altri
files i quali rappreseentano il cuore dell'applicazione che puo' quindi
essere rimaneggiata senza andare a toccare i dati.
Post by Angelfall
Insomma i dati di una tabella Access sono scalabili verso sistemi piu'
potenti ed interrogabili da applicazioni esterne. La roba di FM se ne
resta dentro a casa sua e non puoi migrarla verso nient'altro.
Io conosco poco Access e me ne scuso, probabilmente avro' anche le idee
confuse su cio' che e' lo strato presentation, ma ho idea che anche tu
ti sia fermato ai limiti di FMP senza vederne il superamento e senza
affrontarlo con piu' impegno :)
Post by Angelfall
Post by SAP
Capisco la comodita' inserire un file di access nell'inetpub e vederlo
interrogare come fosse gia' aperto, ma e' anche grazie a queste cose che
il web pullula di siti scritti coi piedi, di linguaggi di scripting
proprietari che abbisognano per forza di sistemi windows, di
vulnerabilita' piu' o meno latenti sempre piu' diffuse.
Senti: la prima vulnerabilita' conclamata di db su web e' un premio
ambito che ha vinto, circa tre anni fa, il buon FileMaker, quando hanno
scoperto che si potevano costruire delle semplici stringhe URL per
cavarne fuori i dati.
Un baco in web companion, che per inciso va' attivato, altrimenti non ci
arrivi via www.
Post by Angelfall
Non mi risulta che lo stesso possa essere fatto attraverso ASP.
ASP e' un linguaggio di scripting esente da bachi?
Non capisco perche' ci si lamenti del fatto che FMP e' un DB
proprietario e poi si finisca per cadere dalla padella nella brace.
Access oltre a non essere tutta sta gran cosa e' uno dei grimaldelli
piu' potenti di MS per imporre i propri standard a livello planetario,
tra i quali quello di costruire i siti in ASP.
Post by Angelfall
Un database Access viene aperto tramite ODBC o ADO, supporta vari sistemi
di autenticazione (cosa che FM *non* fa in questa funzione)
FMP supporta vari livelli di autenticazione, gia' dalla versione 6 anche
a livello di singolo record, se poi ti guardi i molteplici livelli di
autenticazione e la granularita' che trovi nella versione 7 e che mi
sono appena appena guardato, ti viene il mal di testa...
Post by Angelfall
e non pretende di mettere in piedi un intero motore di server web per
pubblicare i dati (motore, quello si', bucato come pochi)
Uh?
Maggiori info?
Parli del noto bug di web companion?
Web companion esiste solo sul client, se parli del server invece ti
informo che NON puo' pubblicare su web in alcun modo (solo nell'ultima
versione la 7 puo' farlo ma attraverso XML credo).
O non ho capito bene io o non ti sei spiegato bene tu, fammi capire, ti
prego.
Post by Angelfall
ma collabora con il server web installato sulla macchina. Inoltre per
l'autenticazione puo' anche appoggiarsi ai servizi di qualche DBMS piu'
evoluto che gestisca metodi piu' avanzati (again MSSQL oppure Oracle). Hai
provato sul serio a mantenere un sito web generato da FM? E pensi che
*quello* sia sicuro??
Veramente ne ho alcuni che funzionano da ANNI pubblicati su indirizzi IP
pubblici senza NESSUN firewall, su macchine senza antivirus ne firewall
personali attivati.
MAI avuto un problema che sia uno.

Lentezza si , parecchia, sopratutto in siti ad alto traffico e
transazioni con gestione multiutente.
Ma ho risolto con Lasso e una gestione oculata dei dati.
Questo per es. <jjj.gvevtvbpb.vg> e' basato TUTTO su FMP e nonostante
qualche bachettino, gira egregiamente.
Post by Angelfall
Post by SAP
Post by Angelfall
L'interfaccia per effettuare le query in FM e' una genialata, ma devi
fare le cose come dice lui o nulla, anche qui l'impossibilita' di usare
SQL e' limitante.
Again: FMP non e' un DB SQL, basta saperlo e usralo per quello che ti
da'.
Again: SQL e' un linguaggio, non una struttura. FM non ti da' troppa
roba per poter essere preso sul serio ad un livello appena piu' alto di
quello personale.
Santo Dio.
Si puo' sbagliare scrivendo "FMP non e' un DB SQL" al posto di "FMP non
e' un DB che supporta SQL", ma pensavo di essere facilmente capito,
chiedo venia.
Post by Angelfall
Post by SAP
La 7 non la conosco bene e mi sta' gia' sul cazzo per essersi
"accessizzata" con la storia dei DB multitabellari, pensa un po' :-D
Ti fa cosi' schifo che *finalmente* se io metto in relazione A con B e B
con C, in una form di A possa vedere i dati di C, senza dover creare
orridi campi calcolati in B? Ma che male ti ha fatto la relazionalita'?
Non mi risulta.
Stabilite le relazioni nelle tabelle, sulla 7 si possono vedere i dati
di una tabella remota e non direttamente relazionata con la prima, senza
alcuna difficolta.
Post by Angelfall
E comunque: la 7 parla solo con la 7 e nient'altro, quindi OsX o niente.
Capirai.
Si importano gli archivi in automatico (o quasi).
Post by Angelfall
Quindi se hai un tot di licenze 6 le devi upgradare *tutte* a 7. E non
solo i client: upgrada pure tutti i server.
Proprio bravi, davvero.
E' stato cosi' anche nel passaggio dalla versione 4 alla 5, non mi pare
ti lamentasti troppo allora.
il formato dei files 3-4 era lo stesso, quindi il server per entrambe le
versioni era il 3.
Analogamente il formato dei files tra la versione 5 e 6 e' lo stesso e
il server e' il 5.x per entrambi.
Ora si e' fatto lo STESSO salto.
--
Giocare col mondo, facendolo a pezzi...
Bambini che il sole, ha ridotto gia'... vecchi.
Angelfall
2004-12-16 00:38:13 UTC
Permalink
Post by SAP
Post by Angelfall
Post by SAP
Ma FileMaker NON e' un DB SQL.
E neanche Access lo e': SQL sta per System Query Language, e' un
*linguaggio* di query, con la struttura relazionale c'entra nulla.
Questo lo so' perfettamente, probabilmente e' colpa mia che non riesco a
spiegarmi, ma volevo semplicemente dire che FMP non ha MAI supportato
SQL come linguaggio di query, almeno non in modo pieno e bidirezionale.
E questo che io gli imputo ;)
Ho capito che hai capito, comunque.
Post by SAP
Post by Angelfall
Infatti ho detto che Access ha la *possibilita'* di esprimere delle
query in SQL e questo ti apre un mondo che con FM ti e' precluso, quello
di dialogare con basi di dati gestite da altri sistemi (Oracle
anybody?).
Ma in casa mia, per archiviare i CD audio, mi serve la potenza di un
Oracle?
Ovviamente no.
Post by SAP
O un Db che supporti SQL?
Ecco, questo magari si'. Hai degli autori, hai dei libri: inserisci un
tot di autori e poi inserisci i libri pescando gli autori dalla loro
tabella. Relazioni autori e libri e gli autori che non hanno un libro,
nel tuo sistema, non esistono piu'. Ti pare una maniera logica di
funzionare? Questo e' un left join e non mi pare fantascienza, puo'
capitare che serva, ad esempio se vuoi sapere quali autori sono
'orfani'.
Post by SAP
E comunque, nella versione 6 che ho a disposizione si puo' interagire
con qualunque base dati ODBC supportata da OsX (anche con driver di
terze parti) per eseguire query standard SQL e importare e manipolare
gruppi di dati provenienti dalle piu' disparate fonti.
Certo, puoi *importarle*, questo lo so e lo faccio (visto che e' l'unica
speranza). Pero' non puoi collegarle dinamicamente alle tue tabelle
lasciandole li' dove sono, nel loro sistema. Importandole crei
ridondanza.
Anche SQL serve solo ad importare, non ad interrogare e costruire un
recordset oppure un cursore. Questo non e' un modo dinamico di
interagire con fonti dati esterne.
Post by SAP
Se avessi dato un'occhiata alla funzione "esegui SQL" a disposizione
negli script probabilmente non avresti detto il periodo sopra citato.
Con un po' di sforzo si potrebbe usare FMP come front end per
un'estrapolazione mirata di dati da fonti dati molto piu' estese e
complesse.
No, non si puo'.
Post by SAP
ho solo stigmatizzato un modo di rappresentare la
strutturazione dei dati di Access che ho sempre trovato astruso e
inutilmente barocco.
Ecco, questo e' interessante: cosa c'e' di barocco in Access? Mi sembra
vero il contrario. Miiii, come siamo diversi ;)
Post by SAP
Post by Angelfall
Ma stiamo parlando di un db: sai cosa fa un right join? Permette di
visualizzare *tutti* i record della tabella A e aggiungere, solo nel
caso che venga soddisfatta la condizione di relazione, i dati della
tabella B. Beh, questa cosa semplice in FM *non* *si* *puo'* *fare*.
Non so' se ho ben capito, se si', la 7 di sicuro lo fa'.
No, continua a non farlo, vedi l'esempio sopra di autori e libri.
Post by SAP
Post by Angelfall
Post by SAP
Post by Angelfall
Non si possono collegare tabelle esterne in maniera dinamica.
Questa non l'ho capita.
Mmmmmh, facciamo un esempio: ho due-tre tabelle sul mio pc che pero'
hanno bisogno di relazionarsi con una tabella (o meglio: una vista
logica) che risiede su altro DBMS. Con Access, posto di possedere il
driver ODBC giusto, dichiaro la tabella nel mio db locale e la uso, che
venga da Oracle, da MS-SQL, da altro pc, da Excel, da file di testo, qui
o attraverso internet poco importa; con FM non posso collegare *nulla*
se non altre tabelle FM e solo dalla mia rete locale.
Ma davvero in uno scenario di piccolissima azienda o studio grafico, o
ambito casalingo hai bisogno di queste cose?
In una realta' strutturata ne hai bisogno anche se l'ufficio e' molto
piccolo. Non puoi stare a convertire ogni singolo dato in FM, e' un
suicidio.
Post by SAP
E se e' cosi' potente, perche' quando si fa' davvero sul serio tutti
sono pronti a sparargli addosso dicendo che e' inadeguato?
Intendi Access? E' sicuramente inadeguato se cerchi di usarlo come DBMS,
guadagna parecchio se lo usi per il suo lavoro naturale: fornire il
front-end a DBMS.
Post by SAP
Post by Angelfall
Post by SAP
Non mi risulta proprio.
Anzi la scrittura su file esterni di appoggio e' supportata fin dalla
versione 3.
Puoi creare/scrivere/aprire un file di testo? E come?
Sicuramente non puoi ottenere una semplicissima lista dei file presenti
in una directory.
FMP si integra ocn AppleScript in modo molto completo, tramite AS puoi
fare quello che vuoi: ottenere listati di directory, manipolarle, creare
files di testo, spostare files, copiarli, cancellarli e sotto OsX
accedere addirittura a tutto l'ambiente Unix.
Non ti pare abbastanza?
Mi pare abbastanza se non fosse che... non funziona sotto Windows :)
Adios allo sbandierato cross-platform, gli costava proprio cosi' tanto
richiamare quelle due librerie di sistema necessarie all'uopo, a seconda
del sistema operativo? E comunque, non e' bello dire che per certe cose
ti devi *pure* studiare AppleScript.
Post by SAP
Post by Angelfall
Post by SAP
Troppo lento, e' un problema strutturale di FMP.
Lo si sente sopratutto se si usa FMP come DB per web e li' e' una croce,
ma per usi personali sul proprio PC non si nota
Prova ad usarlo su dieci-ventimila record e fagli fare un sort con campi
di una tabella collegata e poi ne riparliamo: belle le barre di
progresso, nevvero? ;-)
Uh?
Ventimila record FMP se li gestisce abbastanza bene se utilizzato con le
giuste ottimizzazioni del caso.
La mia esperienza e' diversa: appena gli scrivi un'interrogazione che
sfrutta una relazione che non gli avevia mai fatto si reindicizza pure
il ciborio, davvero.
Post by SAP
Post by Angelfall
Post by SAP
, in caso di rete locale
invece il server di FMP integra un motore molto piu' veloce.
Mai provato, troppo caro per l'unica cosa che fa.
Certo, per essere caro e' caro, ma non e' l'unica cosa che fa', puoi per
esempio schedulare il salvataggio dei files anche quando sono aperti,
incorpora un motore molto piu' potente e veloce, consente la
pubblicazione e distrubuzione dei plug-in di terze parti eventualmente
utilizzati nelle proprie soluzioni, ecc.
Ma insomma, non e' che deve fare poi tantissime cose, e' un sistema di
host dei DB, null'altro.
Mmmmh, non gestisce i transaction log, serve solo a pubblicare FM per
client FM e non per ODBC. Poco, per i miei sofisticati gusti.
Post by SAP
Angelfall, i driver di solito si scrivono per applicazioni che girano
come i demoni mysqld, che aprono socket e si comportano come server.
Il pastrocchioproprietario e' certamente proprietario, ma non possiamo
chiamarlo pastrocchio dal momento che e' un modo di lavorare coi dati
semplicemente diverso.
Non capisco: in un file Access ci sono le tabelle dei dati, ma anche le
relazioni, le form, i report, le macro e un sacco s'altra roba. Quando
utilizzo il driver per pubblicarlo tramite ODBC ne vedo solo le tabelle
dei dati, come uno si aspetta da ODBC. Dov'e' il problema nel farlo
anche per FM? Niente: tutta l'applicazione aperta, cosa che in Windows
2000, tanto per dirne uno, ti costringe a loggarti in una sessione ed
aprire FM per attivare la condivisione ODBC.
Post by SAP
Io pensavo che ancora non si potesse fare di interrogarlo in ODBC.
Certo che non e' nato per quello ed e' ovvio che lo facci amalissimo.
Invece le query SQL da FMP verso fonti esterne funzionano abbastanza
bene.
Vedi che mi dai ragione? Chiuso a riccio in se' stesso, manco la difesa
della Triestina di Rocco ;-)
Post by SAP
Post by Angelfall
Quindi se tu becchi un ufficio che utilizza FM da un tot di tempo *e* ha
esigenze di ODBC, gli smonti tutta la struttura db che ha in FM, la
ricrei in MySQL, gli riscrivi tutte le applicazioni che corrispondano a
quello che utilizzavano in FM e gli impedisci di usare quello che hanno
usato fino ad oggi perche' tanto e' cieco come una talpa?
Mah.
Costoso, se non altro.
No, in certi casi puo' essere l'unica cosa intelligente che puoi fare
per loro.
Se FMP ha raggiunto i suoi limiti e le richieste sono di una struttura
dati piu' solida che deve reggere un numero di record e transazioni
molto elevato, allora si deve per forza passare a qualcosa di piu'
potente.
Se quelli dell'ufficio A hanno esigenza di comunicare con i nuovi
colleghi dell'ufficio B e quelli del B hanno sempre usato Access, invece
che il FM dell'ufficio A, non significa che abbiamo bisogno di qualcosa
di potente, ma di un modo qualunque di parlarci e condividere i dati. La
condivisione tramite ODBC o altro serve proprio a questo e la rende
economica anche per piccole realta'.
Post by SAP
Una cosa ancora piu' intelligente potrebbe essere quella di mantenere
FMP come front-end verso applicativi piu' potenti per la gestione dei
dati e spostare i dati stessi da FMP a un diverso DB, affinche' il modo
di lavorare abituale del cliente possa cambiare in minima parte e dia
l'impressione che non si sia modificato troppo.
Uh? E come fai, visto che FM al massimo quei dati li importa?
Post by SAP
E invece si.
E' possibile farlo e ci sono degli esempi REALI.
Se fossei stato al DevCon, la conferenza degli sviluppatori italiani di
FMP tenutasi quest'anno per la prima volta a Firenze, ti saresti basito
piu' piu' volte (come ha fatto del resto il sottoscritto), nel vedere
quanto l'ingegno possa sopperire a talune effettive mancanze.
Si', ho visto una serie di lavori interessanti, ma dannazione, gli
sviluppatori in FM sono costretti a reinventarsi l'acqua calda ad ogni
step che scrivono. Possibile che in Filemaker non se ne rendano conto?
E' possibile anche effettuare una sottospecie di left join, ma l'ingegno
utilizzato e' tale da farti desiderare una bancarella per la vendita di
zucchine, come lavoro futuro.
Post by SAP
Certo, esistono limitazioni ad una netta separazione tra i dati e la
struttura e FMP non aiuta affatto, ma si puo' utilizzando gli strumenti
messi a disposizione a far si che i dati risiedano solo in alcuni files
e che non vengano affatto toccati, che cioe' siano meri vuoti
contenitori, senza script, senza comandi, campi calcolati o altro, in
modo tale da concentrare tutte le funzioni dell'applicazione in altri
files i quali rappreseentano il cuore dell'applicazione che puo' quindi
essere rimaneggiata senza andare a toccare i dati.
Una cosa che se uno la apre ci mette due mesi a capirla. Ho aperto una
gestione di calendario di queste che vanno per la maggiore: sembra un
incubo di Escher una sera che ha mangiato pesante :)
Post by SAP
Post by Angelfall
Insomma i dati di una tabella Access sono scalabili verso sistemi piu'
potenti ed interrogabili da applicazioni esterne. La roba di FM se ne
resta dentro a casa sua e non puoi migrarla verso nient'altro.
Io conosco poco Access e me ne scuso, probabilmente avro' anche le idee
confuse su cio' che e' lo strato presentation, ma ho idea che anche tu
ti sia fermato ai limiti di FMP senza vederne il superamento e senza
affrontarlo con piu' impegno :)
Orpo, ci porto avanti tutta la presidenza di ingegneria con quel fottuto
bastardo: non vedi con che nonchalance ne parlo?
Sono incavolato proprio perche' lo uso pesantemente.
Post by SAP
Post by Angelfall
Post by SAP
Capisco la comodita' inserire un file di access nell'inetpub e vederlo
interrogare come fosse gia' aperto, ma e' anche grazie a queste cose che
il web pullula di siti scritti coi piedi, di linguaggi di scripting
proprietari che abbisognano per forza di sistemi windows, di
vulnerabilita' piu' o meno latenti sempre piu' diffuse.
Senti: la prima vulnerabilita' conclamata di db su web e' un premio
ambito che ha vinto, circa tre anni fa, il buon FileMaker, quando hanno
scoperto che si potevano costruire delle semplici stringhe URL per
cavarne fuori i dati.
Un baco in web companion, che per inciso va' attivato, altrimenti non ci
arrivi via www.
Ho capito, ma se lo attivi e' bacato. Pochi cavoli.
Post by SAP
Post by Angelfall
Non mi risulta che lo stesso possa essere fatto attraverso ASP.
ASP e' un linguaggio di scripting esente da bachi?
ASP e' server-side, la logica di uno script e' nascosta. Non puoi sapere
*nulla* della fonte dati da ASP.
Post by SAP
Non capisco perche' ci si lamenti del fatto che FMP e' un DB
proprietario e poi si finisca per cadere dalla padella nella brace.
Access oltre a non essere tutta sta gran cosa e' uno dei grimaldelli
piu' potenti di MS per imporre i propri standard a livello planetario,
tra i quali quello di costruire i siti in ASP.
Uh?? Con ASP posso usare quello che voglio, anche FM tramite ODBC se non
diventassi vecchio nell'attesa che mi tornino indietro i dati. ASP ed
Access hanno poco a che fare: meglio dire ASP e MSDE (al limite) che
sono aggratise ed un'accoppiata molto piu' potente.
Post by SAP
Post by Angelfall
Un database Access viene aperto tramite ODBC o ADO, supporta vari sistemi
di autenticazione (cosa che FM *non* fa in questa funzione)
FMP supporta vari livelli di autenticazione, gia' dalla versione 6 anche
a livello di singolo record, se poi ti guardi i molteplici livelli di
autenticazione e la granularita' che trovi nella versione 7 e che mi
sono appena appena guardato, ti viene il mal di testa...
Si', ma *non* intrinsecamente dalle altre applicazioni. Non attraverso
il web.
Post by SAP
Post by Angelfall
e non pretende di mettere in piedi un intero motore di server web per
pubblicare i dati (motore, quello si', bucato come pochi)
Uh?
Maggiori info?
Parli del noto bug di web companion?
Web companion esiste solo sul client, se parli del server invece ti
informo che NON puo' pubblicare su web in alcun modo (solo nell'ultima
versione la 7 puo' farlo ma attraverso XML credo).
Infatti per pubblicare su web si usava il tristemente noto Unlimited che
altro non era che... FMP senza la limitazione a dieci client, per il
resto la stessa identica zuppa, con lo stesso bug dentro web companion.
Un cratere, piu' che un bug.
Post by SAP
Post by Angelfall
ma collabora con il server web installato sulla macchina. Inoltre per
l'autenticazione puo' anche appoggiarsi ai servizi di qualche DBMS piu'
evoluto che gestisca metodi piu' avanzati (again MSSQL oppure Oracle). Hai
provato sul serio a mantenere un sito web generato da FM? E pensi che
*quello* sia sicuro??
Veramente ne ho alcuni che funzionano da ANNI pubblicati su indirizzi IP
pubblici senza NESSUN firewall, su macchine senza antivirus ne firewall
personali attivati.
MAI avuto un problema che sia uno.
E il bug? Sicuro sicuro che quel server sia cosi' corazzato? Oppure
semplicemente a nessuno e' mai venuto in mente di analizzarne gli
eventuali e possibili attacchi?
Post by SAP
Santo Dio.
Si puo' sbagliare scrivendo "FMP non e' un DB SQL" al posto di "FMP non
e' un DB che supporta SQL", ma pensavo di essere facilmente capito,
chiedo venia.
Lavoro con degli ingegneri, divento palloso anch'io, spesso :-)
Post by SAP
Post by Angelfall
Post by SAP
La 7 non la conosco bene e mi sta' gia' sul cazzo per essersi
"accessizzata" con la storia dei DB multitabellari, pensa un po' :-D
Ti fa cosi' schifo che *finalmente* se io metto in relazione A con B e B
con C, in una form di A possa vedere i dati di C, senza dover creare
orridi campi calcolati in B? Ma che male ti ha fatto la relazionalita'?
Non mi risulta.
Stabilite le relazioni nelle tabelle, sulla 7 si possono vedere i dati
di una tabella remota e non direttamente relazionata con la prima, senza
alcuna difficolta.
Stiamo dicendo la stessa cosa: per una volta che io sono contento di una
feature del 7 (la relazione multitabellare) e tu no, mi cazzi al
contrario?
Stai barando ;)
Post by SAP
Post by Angelfall
E comunque: la 7 parla solo con la 7 e nient'altro, quindi OsX o niente.
Capirai.
Si importano gli archivi in automatico (o quasi).
Ehm, certo: e chi non ha OsX? E se invece da 7 ti dovesse servire di
attaccarti ad un server 6 una volta che vai in giro col tuo notebook?

Aaaaaaah, bastardi, non mi ci far pensare.
--
Quando c'era lui i treni partivano in orario
Quando c'era lui ci deportavano in orario
SAP
2004-12-16 12:21:24 UTC
Permalink
Post by Angelfall
Post by SAP
Questo lo so' perfettamente, probabilmente e' colpa mia che non riesco a
spiegarmi, ma volevo semplicemente dire che FMP non ha MAI supportato
SQL come linguaggio di query, almeno non in modo pieno e bidirezionale.
E questo che io gli imputo ;)
Ah beh, ma non e' che ci siamo svagliati stamani e abbiamo visto questi
limiti: li ha sempre avuti!
Anzi, prima era pure peggio!

Insomma, lo sappiamo che la minestra e' quella li', mica ce la dobbiamo
mangiare per forza.

Certo a chi mi chiede un DB veloce, per scopi personali su Mac, il primo
consiglio che gli do' e' FileMaker.
Post by Angelfall
Post by SAP
O un Db che supporti SQL?
Ecco, questo magari si'. Hai degli autori, hai dei libri: inserisci un
tot di autori e poi inserisci i libri pescando gli autori dalla loro
tabella. Relazioni autori e libri e gli autori che non hanno un libro,
nel tuo sistema, non esistono piu'. Ti pare una maniera logica di
funzionare?
Eh???
No, dico, basta deselezionare dalla relazione il box con la voce: "Se si
elimina un record di questo file elimina anche i record collegati".
Mai successo di cancellare per errore i record correlati, a meno di non
volerlo espressamente.
Post by Angelfall
Questo e' un left join e non mi pare fantascienza, puo' capitare che
serva, ad esempio se vuoi sapere quali autori sono 'orfani'.
Continuo a non capire: non e' cosi' come dici che si comporta FMP.
Post by Angelfall
Certo, puoi *importarle*, questo lo so e lo faccio (visto che e' l'unica
speranza). Pero' non puoi collegarle dinamicamente alle tue tabelle
lasciandole li' dove sono, nel loro sistema. Importandole crei
ridondanza.
Puoi gestire i dati estratti con files di appoggio che vengono puliti di
volta in volta, e' come crearti un sistema di caching, in fondo in fondo
non si lavora mai con TUTTI i dati e gli utenti tendono a manipolare
sempre i soliti.
Con un pizzico di intelligenza e qualche artificio si puo' lavorare
benissimo in questo modo, costruendoti tutti i report che ti servono.
Post by Angelfall
Post by SAP
Se avessi dato un'occhiata alla funzione "esegui SQL" a disposizione
negli script probabilmente non avresti detto il periodo sopra citato.
Con un po' di sforzo si potrebbe usare FMP come front end per
un'estrapolazione mirata di dati da fonti dati molto piu' estese e
complesse.
No, non si puo'.
Si puo', fidati :)
Post by Angelfall
Post by SAP
ho solo stigmatizzato un modo di rappresentare la
strutturazione dei dati di Access che ho sempre trovato astruso e
inutilmente barocco.
Ecco, questo e' interessante: cosa c'e' di barocco in Access? Mi sembra
vero il contrario. Miiii, come siamo diversi ;)
Appena lo riprendo in mano ti faccio un elenco eh...
Dammi tempo, e' un po' che non lo guardo.
Ricordo che mi fece una pessima impressione, saro' limitato io, che ti
devo dire...
Post by Angelfall
Post by SAP
Non so' se ho ben capito, se si', la 7 di sicuro lo fa'.
No, continua a non farlo, vedi l'esempio sopra di autori e libri.
L'esempio che mi hai fatto Angelfall, (se ho ben capito) non sta' ne' in
cielo ne' in terra come ti ho detto prima...
Post by Angelfall
Post by SAP
FMP si integra ocn AppleScript in modo molto completo, tramite AS puoi
fare quello che vuoi: ottenere listati di directory, manipolarle, creare
files di testo, spostare files, copiarli, cancellarli e sotto OsX
accedere addirittura a tutto l'ambiente Unix.
Non ti pare abbastanza?
Mi pare abbastanza se non fosse che... non funziona sotto Windows :)
Sotto Win l'ho usato davvero pochissimo, ma non puo' richiamare script
analogamente ad AS in VB?
Rimarrebbe la gravissima incompatibilita' delle soluzioni, ma almeno
potresti supplire alla mancanza di alcune funzioni.
Post by Angelfall
Adios allo sbandierato cross-platform
Ok, siamo daccordo.
Post by Angelfall
gli costava proprio cosi' tanto richiamare quelle due librerie di sistema
necessarie all'uopo, a seconda del sistema operativo?
Boh?
Lo chiedi a me? :)
Comunque non e' che Access sia sto gran prodotto cross-platform,
diciamocelo eh :P
Post by Angelfall
E comunque, non e' bello dire che per certe cose ti devi *pure* studiare
AppleScript.
A parte che il suo analogo nel mondo PC (VB?) mi sembra molto piu'
complesso rispetto alla facilita' di AS, ma in generale anche
tralasciando questo aspetto quando lavori in un sistema integrato che
richiama in gioco anche componenti legate al sistema operativo, ai files
ecc. mi sa' che non puoi proprio evitarlo di studiare anche altro...
Post by Angelfall
Post by SAP
Uh?
Ventimila record FMP se li gestisce abbastanza bene se utilizzato con le
giuste ottimizzazioni del caso.
La mia esperienza e' diversa: appena gli scrivi un'interrogazione che
sfrutta una relazione che non gli avevia mai fatto si reindicizza pure
il ciborio, davvero.
Le indicizzazioni come le query vanno gestite.
Post by Angelfall
Non capisco: in un file Access ci sono le tabelle dei dati, ma anche le
relazioni, le form, i report, le macro e un sacco s'altra roba. Quando
utilizzo il driver per pubblicarlo tramite ODBC ne vedo solo le tabelle
dei dati, come uno si aspetta da ODBC. Dov'e' il problema nel farlo
anche per FM? Niente: tutta l'applicazione aperta, cosa che in Windows
2000, tanto per dirne uno, ti costringe a loggarti in una sessione ed
aprire FM per attivare la condivisione ODBC.
E questo e' un limite e lo sappiamo da sempre (remember minestra?).
Pero' se e' un DB personale, che viene hostato dal programma, non
possiamo farne un dramma e sopratutto lamentarci quando vorremmo
trattarlo alla stregua di un vero DB interrogabile in ODBC e non
funziona.

Quando i bisogni sono quelli si cambia cavallo, FMP non va' bene.
Post by Angelfall
Se quelli dell'ufficio A hanno esigenza di comunicare con i nuovi
colleghi dell'ufficio B e quelli del B hanno sempre usato Access, invece
che il FM dell'ufficio A, non significa che abbiamo bisogno di qualcosa
di potente, ma di un modo qualunque di parlarci e condividere i dati. La
condivisione tramite ODBC o altro serve proprio a questo e la rende
economica anche per piccole realta'.
IMHO, in questi casi conviene proprio trovare un layer di compatibilita'
che renda universalmente raggiungibile la base dati.
ODBC puo' andare bene, FMP no.
Probabilmente come ho gia' detto si puo' lavorare (ma ci vuole ingegno e
tempo) sul creare una soluzione ad hoc con FMP per l'ufficio A in modo
che consulti la banca dati via ODBC come un piccolo front-end, ma tutto
dipende dalle esigenze e in ogni caso comporta delle limitazioni.
Post by Angelfall
Post by SAP
Una cosa ancora piu' intelligente potrebbe essere quella di mantenere
FMP come front-end verso applicativi piu' potenti per la gestione dei
dati e spostare i dati stessi da FMP a un diverso DB, affinche' il modo
di lavorare abituale del cliente possa cambiare in minima parte e dia
l'impressione che non si sia modificato troppo.
Uh? E come fai, visto che FM al massimo quei dati li importa?
Come ti ho detto piu' sopra, costruendo una struttura di files di
appoggio che si riempiono e si svuotano come polmoni in un sistema di
caching dei dati, cosi' che l'utente (ovviamente giudato e non libero di
fare i casi suoi) lavori indirettamente sulla fonte primaria.
Il che ha indubitabilmente degli svantaggi ma anche alcuni vantaggi non
indifferent.
Lavorando indirettamente infatti sulla fonte primaria, tutti i controlli
e le limitazioni imposte all'utente, possono risiedere su FileMaker.
Post by Angelfall
Si', ho visto una serie di lavori interessanti, ma dannazione, gli
sviluppatori in FM sono costretti a reinventarsi l'acqua calda ad ogni
step che scrivono. Possibile che in Filemaker non se ne rendano conto?
E' possibile anche effettuare una sottospecie di left join, ma l'ingegno
utilizzato e' tale da farti desiderare una bancarella per la vendita di
zucchine, come lavoro futuro.
Per qualcuno e' una sfida contiua :P
Post by Angelfall
Una cosa che se uno la apre ci mette due mesi a capirla. Ho aperto una
gestione di calendario di queste che vanno per la maggiore: sembra un
incubo di Escher una sera che ha mangiato pesante :)
LOL :)
Post by Angelfall
Post by SAP
Un baco in web companion, che per inciso va' attivato, altrimenti non ci
arrivi via www.
Ho capito, ma se lo attivi e' bacato. Pochi cavoli.
Ma no!
Lo era in una sua specifica versione subito upgradata.
Difficile che tu abbia proprio quella.
Post by Angelfall
Post by SAP
ASP e' un linguaggio di scripting esente da bachi?
ASP e' server-side, la logica di uno script e' nascosta. Non puoi sapere
*nulla* della fonte dati da ASP.
Si, ma io parlavo del fatto che e' una roba ultraproprietaria.
Post by Angelfall
Si', ma *non* intrinsecamente dalle altre applicazioni. Non attraverso
il web.
Se vuoi la stessa granularita' nella definizione di utenze e gruppi devi
usare SW middleware come Lasso.
Post by Angelfall
Post by SAP
Veramente ne ho alcuni che funzionano da ANNI pubblicati su indirizzi IP
pubblici senza NESSUN firewall, su macchine senza antivirus ne firewall
personali attivati.
MAI avuto un problema che sia uno.
E il bug?
Minchia angelfall, per quella specifica versione basta un aggiornamento
di pochi K, nelle versioni successive e' andato a posto...
Post by Angelfall
Sicuro sicuro che quel server sia cosi' corazzato? Oppure
semplicemente a nessuno e' mai venuto in mente di analizzarne gli
eventuali e possibili attacchi?
Non lo so' e non mi pongo il problema :)
Tengo tutto aggiornato e faccio manutenzione e backup periodica.
Il fatto e' che sono 5 anni che gira senza un problema che sia uno.
Post by Angelfall
Post by SAP
Non mi risulta.
Stabilite le relazioni nelle tabelle, sulla 7 si possono vedere i dati
di una tabella remota e non direttamente relazionata con la prima, senza
alcuna difficolta.
Stiamo dicendo la stessa cosa: per una volta che io sono contento di una
feature del 7 (la relazione multitabellare) e tu no, mi cazzi al
contrario?
Stai barando ;)
Si, va bene.
Se lo aspettavano tutti una svolta di questo tipo e non dico che non
abbiano fatto bene, ma alcune conti non tornano e secondo me era meglio
puntavano a cose piu' essentiali e a migliorare vecchi ed annosi
problemi prima di introdurre la multitabellarita' all'interno dello
stesso file.

Ti faccio un elenco?
Post by Angelfall
Post by SAP
Capirai.
Si importano gli archivi in automatico (o quasi).
Ehm, certo: e chi non ha OsX? E se invece da 7 ti dovesse servire di
attaccarti ad un server 6 una volta che vai in giro col tuo notebook?
Aaaaaaah, bastardi, non mi ci far pensare.
Ma e' stato cosi' anche prima.
Pensa al passaggio dalla versione 4 alla 5, ma non li voglio certo
difendere, fanno solo il loro sporco interesse, ci mancherebbe
--
Giocare col mondo, facendolo a pezzi...
Bambini che il sole, ha ridotto gia'... vecchi.
Angelfall
2004-12-16 22:36:59 UTC
Permalink
Post by SAP
Post by Angelfall
Post by SAP
O un Db che supporti SQL?
Ecco, questo magari si'. Hai degli autori, hai dei libri: inserisci un
tot di autori e poi inserisci i libri pescando gli autori dalla loro
tabella. Relazioni autori e libri e gli autori che non hanno un libro,
nel tuo sistema, non esistono piu'. Ti pare una maniera logica di
funzionare?
Eh???
No, dico, basta deselezionare dalla relazione il box con la voce: "Se si
elimina un record di questo file elimina anche i record collegati".
Mai successo di cancellare per errore i record correlati, a meno di non
volerlo espressamente.
No, non ci siamo capiti: intendo dire che se effettui un Find, oppure
crei un portale collegato tramite una relazione di questo genere, gli
autori 'orfani' saranno nascosti, non cancellati, ma filtrati.
In quel senso spariscono.
Post by SAP
Post by Angelfall
Questo e' un left join e non mi pare fantascienza, puo' capitare che
serva, ad esempio se vuoi sapere quali autori sono 'orfani'.
Continuo a non capire: non e' cosi' come dici che si comporta FMP.
Ti faccio un altro esempio forse piu' chiaro: poni di avere una tabella
A che contiene degli slot temporali (ad esempio ogni record corrispnde
ad un'ora di un determinato giorno) e hai creato un record in questa
tabella per ogni ora dell'anno. Nella tabella A ci sono quindi 365x24
record, ok?
Poi hai la tabella B che contiene gli eventi che accadono in una
determinata ora di un determinato giorno: ci saranno giorni con eventi
correlati e giorni che non ne hanno. Se tu volessi fare un Find che ti
mostri, secondo una certa condizione, tutti i record della tabella A,
sia che abbiano degli eventi sia che non ne abbiano, beh questo non puoi
farlo, ti salteranno fuori solo i record di A che hanno dei record
correlati in B. Questo comportamento e' tipico dell'INNER JOIN: il
comportamento richiesto (fammi vedere *tutti* i record di A e solo i
dati di B dove esistono) e' il RIGHT o LEFT JOIN.
Post by SAP
Post by Angelfall
Certo, puoi *importarle*, questo lo so e lo faccio (visto che e' l'unica
speranza). Pero' non puoi collegarle dinamicamente alle tue tabelle
lasciandole li' dove sono, nel loro sistema. Importandole crei
ridondanza.
Puoi gestire i dati estratti con files di appoggio che vengono puliti di
volta in volta, e' come crearti un sistema di caching, in fondo in fondo
non si lavora mai con TUTTI i dati e gli utenti tendono a manipolare
sempre i soliti.
Questa soluzione, nel caso di tabelle collegate condivise con utenti di
altri DBMS e' *letale*, significa non rispettare le normali ed accettate
procedure multi-user su un DBMS. Dovresti lockare tutti i record
presenti nella cache per stare sicuro, un assassinio delle performance.
Post by SAP
Post by Angelfall
Post by SAP
Se avessi dato un'occhiata alla funzione "esegui SQL" a disposizione
negli script probabilmente non avresti detto il periodo sopra citato.
Con un po' di sforzo si potrebbe usare FMP come front end per
un'estrapolazione mirata di dati da fonti dati molto piu' estese e
complesse.
No, non si puo'.
Si puo', fidati :)
No, visto che puoi solo importare i dati, sei limitato e rischi di
generare incoerenze nella base di dati collegata. Nessun amministratore
di DBMS lo consentirebbe.
Post by SAP
Post by Angelfall
Post by SAP
Non so' se ho ben capito, se si', la 7 di sicuro lo fa'.
No, continua a non farlo, vedi l'esempio sopra di autori e libri.
L'esempio che mi hai fatto Angelfall, (se ho ben capito) non sta' ne' in
cielo ne' in terra come ti ho detto prima...
No, la cosa che ti dicevo realmente (perche' non c'eravamo capiti) non
si fa neanche nel 7.
Post by SAP
Post by Angelfall
Post by SAP
FMP si integra ocn AppleScript in modo molto completo, tramite AS puoi
fare quello che vuoi: ottenere listati di directory, manipolarle, creare
files di testo, spostare files, copiarli, cancellarli e sotto OsX
accedere addirittura a tutto l'ambiente Unix.
Non ti pare abbastanza?
Mi pare abbastanza se non fosse che... non funziona sotto Windows :)
Sotto Win l'ho usato davvero pochissimo, ma non puo' richiamare script
analogamente ad AS in VB?
No, per nulla: devi costruire librerie in C e metterle nelle estensioni
di FM. Non si puo' fare altro.
Post by SAP
Post by Angelfall
gli costava proprio cosi' tanto richiamare quelle due librerie di sistema
necessarie all'uopo, a seconda del sistema operativo?
Boh?
Lo chiedi a me? :)
Comunque non e' che Access sia sto gran prodotto cross-platform,
diciamocelo eh :P
Access non e' *per niente* cross-platform. Non pretende neanche di
esserlo, in effetti. Pero' c'e' ancora (e lotta con noi) Foxpro!!
Post by SAP
Post by Angelfall
E comunque, non e' bello dire che per certe cose ti devi *pure* studiare
AppleScript.
A parte che il suo analogo nel mondo PC (VB?) mi sembra molto piu'
complesso rispetto alla facilita' di AS, ma in generale anche
tralasciando questo aspetto quando lavori in un sistema integrato che
richiama in gioco anche componenti legate al sistema operativo, ai files
ecc. mi sa' che non puoi proprio evitarlo di studiare anche altro...
Mmmmmh, pero' in Access (o nella sua estensione VBA, come preferisci) ho
degli oggetti gia' pronti che posso inserire nelle form con estrema
facilita', configurandoli come un qualsiasi altro oggetto.
Lo scripting di FM e' carente in parecchie cose: ti pare, ad esempio,
che non possa specificare da script l'ordinamento di un determinato
layout, ma che possa solo richiamare l'utlimo ordinamento?
E' ridicolo.
Post by SAP
Post by Angelfall
Non capisco: in un file Access ci sono le tabelle dei dati, ma anche le
relazioni, le form, i report, le macro e un sacco s'altra roba. Quando
utilizzo il driver per pubblicarlo tramite ODBC ne vedo solo le tabelle
dei dati, come uno si aspetta da ODBC. Dov'e' il problema nel farlo
anche per FM? Niente: tutta l'applicazione aperta, cosa che in Windows
2000, tanto per dirne uno, ti costringe a loggarti in una sessione ed
aprire FM per attivare la condivisione ODBC.
E questo e' un limite e lo sappiamo da sempre (remember minestra?).
Pero' se e' un DB personale, che viene hostato dal programma, non
possiamo farne un dramma e sopratutto lamentarci quando vorremmo
trattarlo alla stregua di un vero DB interrogabile in ODBC e non
funziona.
Quando i bisogni sono quelli si cambia cavallo, FMP non va' bene.
Resta il fatto che con il tanto vituperato Access non ho questo
problema. E' una cosa semplce: separare i dati dalla presentazione anche
a livello operativo, si potrebbe fare, non gli va di farlo.
Pigri, oppure maliziosi?
Post by SAP
Post by Angelfall
Si', ho visto una serie di lavori interessanti, ma dannazione, gli
sviluppatori in FM sono costretti a reinventarsi l'acqua calda ad ogni
step che scrivono. Possibile che in Filemaker non se ne rendano conto?
E' possibile anche effettuare una sottospecie di left join, ma l'ingegno
utilizzato e' tale da farti desiderare una bancarella per la vendita di
zucchine, come lavoro futuro.
Per qualcuno e' una sfida contiua :P
Contenti loro...
Post by SAP
Post by Angelfall
Ho capito, ma se lo attivi e' bacato. Pochi cavoli.
Ma no!
Lo era in una sua specifica versione subito upgradata.
Difficile che tu abbia proprio quella.
Ho capito, ma la figura che ci hanno fatto e' stata orrenda.
Quando abbiamo letto di questa cosa, all'epoca, abbiamo staccato ttutto
FM dal web.
Post by SAP
Si, va bene.
Se lo aspettavano tutti una svolta di questo tipo e non dico che non
abbiano fatto bene, ma alcune conti non tornano e secondo me era meglio
puntavano a cose piu' essentiali e a migliorare vecchi ed annosi
problemi prima di introdurre la multitabellarita' all'interno dello
stesso file.
Ti faccio un elenco?
Vai :)
Post by SAP
Post by Angelfall
Post by SAP
Capirai.
Si importano gli archivi in automatico (o quasi).
Ehm, certo: e chi non ha OsX? E se invece da 7 ti dovesse servire di
attaccarti ad un server 6 una volta che vai in giro col tuo notebook?
Aaaaaaah, bastardi, non mi ci far pensare.
Ma e' stato cosi' anche prima.
Pensa al passaggio dalla versione 4 alla 5, ma non li voglio certo
difendere, fanno solo il loro sporco interesse, ci mancherebbe
Se ho la 5 non posso aprire un file condiviso da una 4? Davvero?
--
Quando c'era lui i treni partivano in orario
Quando c'era lui ci deportavano in orario
Sembro la carta
2004-12-17 07:30:10 UTC
Permalink
Post by Angelfall
No, non ci siamo capiti: intendo dire che se effettui un Find, oppure
crei un portale collegato tramite una relazione di questo genere, gli
autori 'orfani' saranno nascosti, non cancellati, ma filtrati.
In quel senso spariscono.
Ma questo e` ovvio, e succede anche con un gestionale scritto in Access
come in qualunque DB se sfogli per volume. Ovviamente puoi sempre usare
una popup sulla sorgente degli autori, oppure impostare un'altra
relazione "di passaggio" in un layout diverso.
Post by Angelfall
Poi hai la tabella B che contiene gli eventi che accadono in una
determinata ora di un determinato giorno: ci saranno giorni con eventi
correlati e giorni che non ne hanno. Se tu volessi fare un Find che ti
mostri, secondo una certa condizione, tutti i record della tabella A,
sia che abbiano degli eventi sia che non ne abbiano, beh questo non puoi
farlo,
Certo che puoi farlo, ma sara` un Find sulla tabella A.
E` il momento di spolverare la famosa relazione di comodo, o piu`
semplicemente un altro db che cerchi tanto su A quanto su B.
Post by Angelfall
Access non e' *per niente* cross-platform. Non pretende neanche di
esserlo, in effetti. Pero' c'e' ancora (e lotta con noi) Foxpro!!
C'era... M$ lo ha comprato, sciacallato ed ucciso. L'ultima versione per
Mac e` di 10-12 anni fa, la vedo proprio ora davanti a me in cima allo
scaffale, e dirgli che non e` aggiornato e` dire poco (con OS X, poi...)
Post by Angelfall
Ho capito, ma la figura che ci hanno fatto e' stata orrenda.
Quando abbiamo letto di questa cosa, all'epoca, abbiamo staccato ttutto
FM dal web.
Potresti anche aver ragione su tutto, Angelfall, ma questa e` grossa...
Se dopo aver letto una cosa simile avete staccato FMP dal web allora mi
spetto che come minimo abbiate cancellato Internet Explorer da tutte le
macchine con un qualsiasi tipo di collegamento esterno :-)
--
Splendente in eta` acerba di passione
rosso fiammante,
ma senza eta` matura
marcia impostura
Angelfall
2004-12-17 15:04:13 UTC
Permalink
Post by Sembro la carta
Post by Angelfall
No, non ci siamo capiti: intendo dire che se effettui un Find, oppure
crei un portale collegato tramite una relazione di questo genere, gli
autori 'orfani' saranno nascosti, non cancellati, ma filtrati.
In quel senso spariscono.
Ma questo e` ovvio, e succede anche con un gestionale scritto in Access
come in qualunque DB se sfogli per volume. Ovviamente puoi sempre usare
una popup sulla sorgente degli autori, oppure impostare un'altra
relazione "di passaggio" in un layout diverso.
Ma non deve succedre se sfogli per autore: prova, fai una relazione del
genere in FM, fai un find sugli autori che ti riporti anche qualche
campo dei volumi e vedrai che quelli orfani non vengono fuori.
In Access (che poi Access c'entra poco, eventualmente parliamo di Jet
oppure di MSDE) non succede se la relazione e' un left join. Fidati.
Post by Sembro la carta
Post by Angelfall
Poi hai la tabella B che contiene gli eventi che accadono in una
determinata ora di un determinato giorno: ci saranno giorni con eventi
correlati e giorni che non ne hanno. Se tu volessi fare un Find che ti
mostri, secondo una certa condizione, tutti i record della tabella A,
sia che abbiano degli eventi sia che non ne abbiano, beh questo non puoi
farlo,
Certo che puoi farlo, ma sara` un Find sulla tabella A.
E' un FIND sulla *sola* tabella A, ma come fai a vedere quali sono i
giorni vuoti, se non visualizzi anche i dati dalla B?
Post by Sembro la carta
E` il momento di spolverare la famosa relazione di comodo, o piu`
semplicemente un altro db che cerchi tanto su A quanto su B.
?? No, non l'ho capita.
Post by Sembro la carta
Post by Angelfall
Access non e' *per niente* cross-platform. Non pretende neanche di
esserlo, in effetti. Pero' c'e' ancora (e lotta con noi) Foxpro!!
C'era... M$ lo ha comprato, sciacallato ed ucciso. L'ultima versione per
Mac e` di 10-12 anni fa, la vedo proprio ora davanti a me in cima allo
scaffale, e dirgli che non e` aggiornato e` dire poco (con OS X, poi...)
Mi sa che tu dovresti avere ancora la 2.6, mentre la Visual e' uscita
anche per Mac, peccato che sia ferma al 9.
Post by Sembro la carta
Post by Angelfall
Ho capito, ma la figura che ci hanno fatto e' stata orrenda.
Quando abbiamo letto di questa cosa, all'epoca, abbiamo staccato ttutto
FM dal web.
Potresti anche aver ragione su tutto, Angelfall, ma questa e` grossa...
Se dopo aver letto una cosa simile avete staccato FMP dal web allora mi
spetto che come minimo abbiate cancellato Internet Explorer da tutte le
macchine con un qualsiasi tipo di collegamento esterno :-)
Ehm, c'e' una bella differenza di rischio (pure penale) fra
un'applicazione che ti apre come una cozza un pc di un tizio ed un
server che fornisce al mondo intero dati che potrebbero essere riservati
o peggio coperti da privacy.
O no?
--
Quando c'era lui i treni partivano in orario
Quando c'era lui ci deportavano in orario
Sembro la carta
2004-12-17 15:06:52 UTC
Permalink
Infatti non succede se sfogli *in* autore.
Post by Angelfall
In Access (che poi Access c'entra poco, eventualmente parliamo di Jet
oppure di MSDE) non succede se la relazione e' un left join. Fidati.
Lo so, ma non sposta molto :-)
Post by Angelfall
Post by Sembro la carta
Certo che puoi farlo, ma sara` un Find sulla tabella A.
E' un FIND sulla *sola* tabella A, ma come fai a vedere quali sono i
giorni vuoti, se non visualizzi anche i dati dalla B?
B la relazioni ad A, ed A la relazioni a B, se cerchi in A potrai anche
vedere i record correlati in B, e quindi tutti gli scrittori (in A) con
le loro eventuali opere (relazionate in B) li cerchi da A.
Post by Angelfall
Post by Sembro la carta
E` il momento di spolverare la famosa relazione di comodo, o piu`
semplicemente un altro db che cerchi tanto su A quanto su B.
?? No, non l'ho capita.
lo supponevo :-)
Fai un altro db di ricerca, che via macro lancia la ricerca opportuna in
A oppure in B, copiando via script i criteri opportuni.
Post by Angelfall
Ehm, c'e' una bella differenza di rischio (pure penale) fra
un'applicazione che ti apre come una cozza un pc di un tizio ed un
server che fornisce al mondo intero dati che potrebbero essere riservati
o peggio coperti da privacy.
O no?
Beh, non che IE sia stato esente da exploit di questo tipo... :-)
--
Splendente in eta` acerba di passione
rosso fiammante,
ma senza eta` matura
marcia impostura
Marco Fanciullli
2004-12-18 00:53:20 UTC
Permalink
Post by Angelfall
Ehm, c'e' una bella differenza di rischio (pure penale) fra
un'applicazione che ti apre come una cozza un pc di un tizio ed un
server che fornisce al mondo intero dati che potrebbero essere riservati
o peggio coperti da privacy.
Ah, come accadeva con la coppia IIS + SQLServer... ;-)

Marco
SAP
2004-12-19 23:10:46 UTC
Permalink
Angelfall <***@mclink.it> wrote:

Scusa il ritardo con cui scrivo, ma il tempo scarseggia...
Post by Angelfall
No, non ci siamo capiti: intendo dire che se effettui un Find, oppure
crei un portale collegato tramite una relazione di questo genere, gli
autori 'orfani' saranno nascosti, non cancellati, ma filtrati.
In quel senso spariscono.
In realta' ci sono :)
E anche come dice Marco, con un gioco di relazioni puoi farli rientrare
in gioco.
Post by Angelfall
Questa soluzione, nel caso di tabelle collegate condivise con utenti di
altri DBMS e' *letale*, significa non rispettare le normali ed accettate
procedure multi-user su un DBMS. Dovresti lockare tutti i record
presenti nella cache per stare sicuro, un assassinio delle performance.
In effetti, ripensandoci non e' il massimo.
Post by Angelfall
Post by SAP
Si puo', fidati :)
No, visto che puoi solo importare i dati, sei limitato e rischi di
generare incoerenze nella base di dati collegata. Nessun amministratore
di DBMS lo consentirebbe.
Veramente e' colpa mia che faccio il FMP meno intelligente di quello che
sembri: i dati di una fonte ODBC sono solo in lettura fino alla versione
4.1 di FileMaker Pro, dalla v. 5.0 si legge e si scrive.
Post by Angelfall
Post by SAP
Sotto Win l'ho usato davvero pochissimo, ma non puo' richiamare script
analogamente ad AS in VB?
No, per nulla: devi costruire librerie in C e metterle nelle estensioni
di FM. Non si puo' fare altro.
Ma che bella stronzata :-/
Post by Angelfall
Access non e' *per niente* cross-platform. Non pretende neanche di
esserlo, in effetti. Pero' c'e' ancora (e lotta con noi) Foxpro!!
Umamma, cosa mi ricordi.
Peccato che MS ha deciso di affossarlo sul piattaforma Mac, io mi
ricordo solo una cosa vecchissima che installava una quantita'
spropositata di files sul mio disco rigido :)
Post by Angelfall
Post by SAP
A parte che il suo analogo nel mondo PC (VB?) mi sembra molto piu'
complesso rispetto alla facilita' di AS, ma in generale anche
tralasciando questo aspetto quando lavori in un sistema integrato che
richiama in gioco anche componenti legate al sistema operativo, ai files
ecc. mi sa' che non puoi proprio evitarlo di studiare anche altro...
Mmmmmh, pero' in Access (o nella sua estensione VBA, come preferisci) ho
degli oggetti gia' pronti che posso inserire nelle form con estrema
facilita', configurandoli come un qualsiasi altro oggetto.
Scusa l'ignoranza, ma in questo caso lo sono (ignorante): oggetti in che
senso?
Oggetti come nella programmazione Object Oriented o robe che si
appicciano qua' e la' e poi ci si lega delle funzioni?
Nel secondo caso la cosa la fa' anche FMP.
Post by Angelfall
Lo scripting di FM e' carente in parecchie cose: ti pare, ad esempio,
che non possa specificare da script l'ordinamento di un determinato
layout, ma che possa solo richiamare l'utlimo ordinamento?
E' ridicolo.
Questa e' una mancanza effettiva, ma neanche la peggiore in campo
script.
E' un vecchio retaggio della semplificazione tipica del programma cosi'
come lo conosciamo: "trova questi records, ordinali per data, stampa con
questo formato pagina" e poi registri tutto in uno script.
Un'automazione a prova di bimbo scemo.
Questo da una parte e' un bene, da un'altra col tempo e' diventato un
po' una palla al piede.
Post by Angelfall
Resta il fatto che con il tanto vituperato Access non ho questo
problema. E' una cosa semplce: separare i dati dalla presentazione anche
a livello operativo, si potrebbe fare, non gli va di farlo.
Pigri, oppure maliziosi?
Vuoi che ti dica come la penso?
Secondo me non sanno bene che direzione prendere.
Post by Angelfall
Post by SAP
Ma no!
Lo era in una sua specifica versione subito upgradata.
Difficile che tu abbia proprio quella.
Ho capito, ma la figura che ci hanno fatto e' stata orrenda.
Quando abbiamo letto di questa cosa, all'epoca, abbiamo staccato ttutto
FM dal web.
Dai, giu', ma che dici...
Se per ogni vulnerabilita' scoperta invece di scaricare la pezza
apposita mi mettessi a scollegare le macchine che ho in rete, sai quante
ce ne rimarrebbero, via.
Post by Angelfall
Post by SAP
Si, va bene.
Se lo aspettavano tutti una svolta di questo tipo e non dico che non
abbiano fatto bene, ma alcune conti non tornano e secondo me era meglio
puntavano a cose piu' essentiali e a migliorare vecchi ed annosi
problemi prima di introdurre la multitabellarita' all'interno dello
stesso file.
Ti faccio un elenco?
Vai :)
Al primo posto vorrei un nuovo motore, quello attuale fa' schifo.
Lento.
Ma sopratutto (non ci crederai) single-threading.
Che tradotto significa: "finche' ho da eseguire un sort o altra
operazione non ti restituisco il comando".
Un'aberrazione solo a pensarci.
Come seconda cose vorrei una maggior potenza del linguaggio di
scripting, una specie di "secondo livello", cioe' lasciare inalterati i
comandi attuali dello scripting di programma ed abilitare una modalita'
"per esperti" che consenta di accedere a funzionalita' avanzate.
Stesso discorso per la modalita' "macro-recording": possibilita' di
personalizzarla in seguito nei dettagli.
Altra mancanza per gli script fondamentale: non e' possibile ricercare
in un colpo solo quel che si e' inserito o scritto in uno script che e'
LETALE in un progetto complesso con centinaia di script e relazioni
incrociate.
Un supporto piu' esteso dell'SQL.

Ecco, se mi favano ste cose, io della multitabellarita' del 7 potevo
anche fare a meno.
Preferivo alla grande una versione uguale alla 6 con le caratteristiche
di cui sopra che una 7 multitabellare senza neanche una delle mie
richieste.
Post by Angelfall
Se ho la 5 non posso aprire un file condiviso da una 4? Davvero?
Eggia'.
--
Giocare col mondo, facendolo a pezzi...
Bambini che il sole, ha ridotto gia'... vecchi.
Angelfall
2004-12-20 17:21:12 UTC
Permalink
Post by SAP
Scusa il ritardo con cui scrivo, ma il tempo scarseggia...
Post by Angelfall
No, non ci siamo capiti: intendo dire che se effettui un Find, oppure
crei un portale collegato tramite una relazione di questo genere, gli
autori 'orfani' saranno nascosti, non cancellati, ma filtrati.
In quel senso spariscono.
In realta' ci sono :)
E anche come dice Marco, con un gioco di relazioni puoi farli rientrare
in gioco.
Mmmmh, dobbiamo darci un appuntamento, portarci i mac, mangiarci
l'impossibile *e poi* Marco mi dimostra che 'sta cosa funziona senza
usare Applescript, allora e solo allora gli credo ;-)
Post by SAP
Post by Angelfall
Post by SAP
A parte che il suo analogo nel mondo PC (VB?) mi sembra molto piu'
complesso rispetto alla facilita' di AS, ma in generale anche
tralasciando questo aspetto quando lavori in un sistema integrato che
richiama in gioco anche componenti legate al sistema operativo, ai files
ecc. mi sa' che non puoi proprio evitarlo di studiare anche altro...
Mmmmmh, pero' in Access (o nella sua estensione VBA, come preferisci) ho
degli oggetti gia' pronti che posso inserire nelle form con estrema
facilita', configurandoli come un qualsiasi altro oggetto.
Scusa l'ignoranza, ma in questo caso lo sono (ignorante): oggetti in che
senso?
Oggetti come nella programmazione Object Oriented o robe che si
appicciano qua' e la' e poi ci si lega delle funzioni?
Nel secondo caso la cosa la fa' anche FMP.
Normalmente sono controlli ActiveX, di cui esistono sterminate librerie
di terze parti: li installi, li utilizzi all'interno della form e ne
setti proprieta' e metodi, esattamente come se fosse un oggetto
'interno'. Non sapevo che si potesse fare la stessa cosa con FM.
Post by SAP
Post by Angelfall
Resta il fatto che con il tanto vituperato Access non ho questo
problema. E' una cosa semplce: separare i dati dalla presentazione anche
a livello operativo, si potrebbe fare, non gli va di farlo.
Pigri, oppure maliziosi?
Vuoi che ti dica come la penso?
Secondo me non sanno bene che direzione prendere.
La stessa mia idea: si trovano davanti a prodotti di ottimo livello (non
parlo di Acces, ovviamente) e non riescono ad evolvere FM in qualcosa di
realmente al passo con i tempi.
Post by SAP
Post by Angelfall
Post by SAP
Si, va bene.
Se lo aspettavano tutti una svolta di questo tipo e non dico che non
abbiano fatto bene, ma alcune conti non tornano e secondo me era meglio
puntavano a cose piu' essentiali e a migliorare vecchi ed annosi
problemi prima di introdurre la multitabellarita' all'interno dello
stesso file.
Ti faccio un elenco?
Vai :)
Al primo posto vorrei un nuovo motore, quello attuale fa' schifo.
<snip>

A proporti come chairman hai mai pensato?
Post by SAP
Post by Angelfall
Se ho la 5 non posso aprire un file condiviso da una 4? Davvero?
Eggia'.
Mamma mia: l'animaccia loro.
--
Quando c'era lui i treni partivano in orario
Quando c'era lui ci deportavano in orario
SAP
2004-12-20 17:50:33 UTC
Permalink
Post by Angelfall
Mmmmh, dobbiamo darci un appuntamento, portarci i mac, mangiarci
l'impossibile *e poi* Marco mi dimostra che 'sta cosa funziona senza
usare Applescript, allora e solo allora gli credo ;-)
.... Mi piace come idea, sopratutto la parte che riguarda "mangiarci
l'impossibile" :)
Post by Angelfall
Post by SAP
Scusa l'ignoranza, ma in questo caso lo sono (ignorante): oggetti in che
senso?
Oggetti come nella programmazione Object Oriented o robe che si
appicciano qua' e la' e poi ci si lega delle funzioni?
Nel secondo caso la cosa la fa' anche FMP.
Normalmente sono controlli ActiveX, di cui esistono sterminate librerie
di terze parti: li installi, li utilizzi all'interno della form e ne
setti proprieta' e metodi, esattamente come se fosse un oggetto
'interno'. Non sapevo che si potesse fare la stessa cosa con FM.
Eh no.
L'unica cose che ci somiglia e' l'integrazione con AppleScript.

Cmq. ActiveX mi ricorda brutte storie riguardo alla sicurezza intrinseca
del sistema e un brutto thread con GinoPilotino :)
Post by Angelfall
La stessa mia idea: si trovano davanti a prodotti di ottimo livello (non
parlo di Acces, ovviamente) e non riescono ad evolvere FM in qualcosa di
realmente al passo con i tempi.
Sono al guado, la comunita' si aspettava qualcosa di veramente
rivoluzionario con la versione 7 e invece hanno puntato a qualche
ritocco cosmetico e aggiunto poche e contraddittorie funzionalita'.
Insomma, si sono cagati in mano.
So' per certo che se ne sono andati anche sviluppatori di primo piano
che hanno dato vita a progetti alternativi (Servoy) ed e' per questo che
sono rimasti parecchio al palo.

IMHO da un po' di tempo a questa parte guardano al mercato e basta,
tengono in scarsissimo conto i rilievi degli sviluppatori.
Tieni presente che queste cose io le chiedevo fin dalla versione 4!
Post by Angelfall
Post by SAP
Al primo posto vorrei un nuovo motore, quello attuale fa' schifo.
<snip>
A proporti come chairman hai mai pensato?
LOL: col senso degli affari che mi contraddistingue fallirebbero dopo 6
mesi, con un prodotto avanzatissimo immagino :)
Post by Angelfall
Post by SAP
Eggia'.
Mamma mia: l'animaccia loro.
E pure li morte'.
--
Giocare col mondo, facendolo a pezzi...
Bambini che il sole, ha ridotto gia'... vecchi.
Angelfall
2004-12-20 19:35:28 UTC
Permalink
Post by SAP
Cmq. ActiveX mi ricorda brutte storie riguardo alla sicurezza intrinseca
del sistema e un brutto thread con GinoPilotino :)
Ssssssh, zitto che quelle erano le DIRECTx.
--
Quando c'era lui i treni partivano in orario
Quando c'era lui ci deportavano in orario
SAP
2004-12-20 21:34:07 UTC
Permalink
Post by Angelfall
Ssssssh, zitto che quelle erano le DIRECTx.
Azz, minghia, vero e'.
--
Giocare col mondo, facendolo a pezzi...
Bambini che il sole, ha ridotto gia'... vecchi.
Marco Fanciullli
2004-12-18 00:53:19 UTC
Permalink
Post by Angelfall
E neanche Access lo e': SQL sta per System Query Language,
Structured...

Marco
Angelfall
2004-12-20 08:01:03 UTC
Permalink
Post by Marco Fanciullli
Post by Angelfall
E neanche Access lo e': SQL sta per System Query Language,
Structured...
Structured, giusto.
--
Quando c'era lui i treni partivano in orario
Quando c'era lui ci deportavano in orario
Marco Fanciullli
2004-12-18 00:53:19 UTC
Permalink
Post by Angelfall
Post by SAP
Post by Angelfall
Post by SAP
Mah, fammi qualche esempio.
Impossibilita' (*ancora* oggi con la versione 7) di esprimere una query
Ma FileMaker NON e' un DB SQL.
E neanche Access lo e': SQL sta per System Query Language, e' un
Structured...
Post by Angelfall
query in SQL e questo ti apre un mondo che con FM ti e' precluso, quello
Non è il fatto di poter esprimere query in SQL che glielo consente... è
il fatto che può utilizzare librerie di accesso esterne (driver ODBC
specifici, client Oracle, e via elencando).

Di per sè potresti scrivere un programma stupido che si connette alla
porta 1521 di un DB Oracle e rispettando il protocollo di comunicazione
pubblica una stringa che casualmente è una query che segue la sintassi
SQL riconosciuta da Oracle... non puoi dire che il tuo applicativo
permette di parlare con Oracle perchè ti permette di scrivere una query
SQL ma perchè supporta il protocollo di comunicazione.

E' solo per pignoleria. Tutte le tue osservazioni su Access sono da me
condivise anche se per me rimane un prodotto che quando è nato era
favolosamente migliore della concorrenza (DBIII) ma che negli ultimi
cinque anni è diventato semplicemente obsoleto, senza acquisire una
stabilità e una utilizzabilità in linea con l'evoluzione di altri
sistemi RAD per la produzione di applicazioni data bound.
Post by Angelfall
Post by SAP
Non mi risulta proprio.
Anzi la scrittura su file esterni di appoggio e' supportata fin dalla
versione 3.
Puoi creare/scrivere/aprire un file di testo? E come?
Sicuramente non puoi ottenere una semplicissima lista dei file presenti
in una directory.
Sulla carta neanche Oracle può... lo fai in PL/SQL e giù di spool :-)
Post by Angelfall
Tutti gli altri scrivono dei driver, non delle applicazioni intere,
semplicemente perche' utilizzano uno standard invece dell'orrido
pastrocchio proprietario che deve tenere aperto tutto l'ambaradan per
rispondere ad interrogazioni tipo SELECT * FROM CLIENTI
Scusa ma qui non ti seguo. Access ha una componente GUI e una componente
implicita (il motore Jet). Quando da un programma X qualunque (ad
esempio uno scritto in VB) fai una query su un DB Access la componente
Jet viene eseguita. Questo è equivalente a lanciare FM.
Il motore JET interpreta le query che gli vengono passate dal driver che
le converte nel formato interno opportuno.
Il motore di Oracle o di SQL-Server sono in piedi (e pesano decine di MB
in relazione alle dimensioni delle basi dati che gestiscono) quando li
interroghi...
Access non è solo lo strato di presentation: Access è Access (GUI) +
JET. Sono nati insieme e sono stati distribuiti insieme. Che poi si
possano disegnare interfacce e applicazioni in Access che leggono dati
da MySQL è un altro conto. Access da solo, senza un DB dietro (ed il suo
è JET) non serve a nulla. Se vogliamo confrontarlo con FM o con Oracle o
con PostgresSQL o VattelapescaSQL dobbiamo considerarlo per intero.
Altrimenti è meglio paragonarlo ad Omnis7 e ad altri strumenti RAD.

Spero che su questo siamo tutti d'accordo.

Marco

P.S. A me FM ha fatto schifo dal primo momento in cui l'ho visto, al
pari di Access :-)
Angelfall
2004-12-20 08:01:02 UTC
Permalink
Post by Marco Fanciullli
Scusa ma qui non ti seguo. Access ha una componente GUI e una componente
implicita (il motore Jet). Quando da un programma X qualunque (ad
esempio uno scritto in VB) fai una query su un DB Access la componente
Jet viene eseguita. Questo è equivalente a lanciare FM.
E' semplice: puoi installare il motore jet come servizio di sistema,
windows va su lo carica in memoria e finisce li'. FM non ha un
componente simile: il servizio e' garantito solo tirando su l'intera
GUI, quindi entrando in una sessione utente e lanciando l'applicazione
(magari anche in autormatico, ovvio). Uno dei problemi, ad esempio, e'
che se una macchina windows qualsiasi con autologon non abilitato si
riavvia per qualsiasi motivo *non* avvia il server FM automaticamente.
--
Quando c'era lui i treni partivano in orario
Quando c'era lui ci deportavano in orario
SAP
2004-12-20 08:08:41 UTC
Permalink
Uno dei problemi, ad esempio, e' che se una macchina windows qualsiasi con
autologon non abilitato si riavvia per qualsiasi motivo *non* avvia il
server FM automaticamente.
Perche' quello NON e' un server, ma un programma client!
Il server invece c'e' e funziona come servizio di Win, quindi non ha
bisogno dell'autologon.
--
Giocare col mondo, facendolo a pezzi...
Bambini che il sole, ha ridotto gia'... vecchi.
Angelfall
2004-12-20 19:23:32 UTC
Permalink
Post by SAP
Uno dei problemi, ad esempio, e' che se una macchina windows qualsiasi con
autologon non abilitato si riavvia per qualsiasi motivo *non* avvia il
server FM automaticamente.
Perche' quello NON e' un server, ma un programma client!
Il server invece c'e' e funziona come servizio di Win, quindi non ha
bisogno dell'autologon.
Peccato che il server di FM 6 non supportasse proprio ODBC, mentre per
il 7 sono *costretto* a comprare l'advanced: 2500$!!
Duemilacinquecento dollari per avere ODBC+web publishing fatti in
maniera umana. Ma questi so' matti.
--
Quando c'era lui i treni partivano in orario
Quando c'era lui ci deportavano in orario
SAP
2004-12-20 21:34:07 UTC
Permalink
Post by Angelfall
Duemilacinquecento dollari per avere ODBC+web publishing fatti in
maniera umana. Ma questi so' matti.
Yess: lui.
Una bella barcata di soldi, non c'e' che dire.
Mai quanto costano le licenze di MS-SQL pero' :)
--
Giocare col mondo, facendolo a pezzi...
Bambini che il sole, ha ridotto gia'... vecchi.
Angelfall
2004-12-20 22:24:35 UTC
Permalink
Post by SAP
Post by Angelfall
Duemilacinquecento dollari per avere ODBC+web publishing fatti in
maniera umana. Ma questi so' matti.
Yess: lui.
Una bella barcata di soldi, non c'e' che dire.
Mai quanto costano le licenze di MS-SQL pero' :)
Sadly: MSDE e' aggratise.
--
Quando c'era lui i treni partivano in orario
Quando c'era lui ci deportavano in orario
Giovanni Mannarino
2004-12-20 22:52:29 UTC
Permalink
Post by Angelfall
Sadly: MSDE e' aggratise.
Ed è pure potente, ma non ha il limite delle 5 connessioni
contemporanee? Certo che gli ambienti SoHo fino ad una quindicina di
client potrebbero farci un pensierino (ed in Italia sono tanti)...
Angelfall
2004-12-20 23:23:43 UTC
Permalink
Post by Giovanni Mannarino
Post by Angelfall
Sadly: MSDE e' aggratise.
Ed è pure potente, ma non ha il limite delle 5 connessioni
contemporanee? Certo che gli ambienti SoHo fino ad una quindicina di
client potrebbero farci un pensierino (ed in Italia sono tanti)...
Ha quel limite se lo usi su workstation, se lo usi su una licenza server
di Windows vai tranquillo.
--
Quando c'era lui i treni partivano in orario
Quando c'era lui ci deportavano in orario
Giovanni Mannarino
2004-12-20 23:23:42 UTC
Permalink
Post by Angelfall
Ha quel limite se lo usi su workstation, se lo usi su una licenza server
di Windows vai tranquillo.
TY, info gradita :-)

SAP
2004-12-20 23:06:11 UTC
Permalink
Post by Angelfall
Sadly: MSDE e' aggratise.
Ma non e' per gli sviluppatori?
So' di gente che si e' salassata per le licenze di MSSQL da usare a
scopi commerciali.
--
Giocare col mondo, facendolo a pezzi...
Bambini che il sole, ha ridotto gia'... vecchi.
snake
2004-12-20 23:08:13 UTC
Permalink
Post by SAP
Ma non e' per gli sviluppatori?
No asolutamente.
Post by SAP
So' di gente che si e' salassata per le licenze di MSSQL da usare a
scopi commerciali.
Polli da spennare, MySql e' gratis e molto meglio dei prodotti scadenti
Microsoft.

Spendere per spendere, meglio oracle!
SAP
2004-12-20 23:19:04 UTC
Permalink
Post by snake
Polli da spennare, MySql e' gratis e molto meglio dei prodotti scadenti
Microsoft.
Vabbe', era "pour parler".
--
Giocare col mondo, facendolo a pezzi...
Bambini che il sole, ha ridotto gia'... vecchi.
Giovanni Mannarino
2004-12-20 23:21:44 UTC
Permalink
Post by snake
Polli da spennare, MySql e' gratis
Mi sembra che sotto Windows (e comunque su qualsiasi piattaforma se
embedded in applicativi non OpenSource) costi 500 Dollari a licenza.
Post by snake
e molto meglio dei prodotti scadenti Microsoft.
Ha avuto fino a poco fa, ed in parte ha ancora, alcuni limiti abbastanza
pesanti: impossibilità di fare query nidificate, impossibilità di creare
vincoli di integrità referenziali, impossibilità di gestire transazioni.

Se vuoi parlare bene dell'OpenSource (che non significa "gratis") ti
consiglio di dare un occhio a PostgreSQL.

Coccodé Giovanni
fbrzvnrnd
2004-12-14 13:51:49 UTC
Permalink
Post by Mac dal 1993
Uso Access in ufficio e ti assicuro che è un programma tra i più complessi e
articolati tra quelli messi di default.
di default in cosa? access lo paghi.




f.
--
avete mai assaggiato le lame rotanti? http://www.lamerotanti.com
SAP
2004-12-14 14:19:13 UTC
Permalink
fbrzvnrnd
Post by fbrzvnrnd
di default in cosa? access lo paghi.
Chissa'...
--
Giocare col mondo, facendolo a pezzi...
Bambini che il sole, ha ridotto gia'... vecchi.
Enrico Gregorio
2004-12-14 14:07:22 UTC
Permalink
Post by Mac dal 1993
Post by Enrico Gregorio
Non conosco Access, ma ho usato, ahimé, programmi prodotti
in tale ambiente di programmazione (?).
Per fortuna non esistono analoghi sistemi nel mondo Mac.
Per fortuna lo dici tu! Perché credi che abbia scritto questo messaggio se
avessi già visto qualcosa anche solo di vagamente simile per il Mac?
Il fatto di essere (orgogliosamente) utenti Mac non ci deve far calare un
velo sugli occhi e riconoscere che su questo fronte siamo carenti.
Uso Access in ufficio e ti assicuro che è un programma tra i più complessi e
articolati tra quelli messi di default.
A proposito, Access è inserito nell'Office di Window, mentre il Mac ti mette
al massimo un Outlook rinominandolo Entourage che fa più fine.
Post by Enrico Gregorio
A proposito di Access: dovrebbe essere pronunciato "Aksèss"
ma moltissimi usano pronunciare "Àccess" (con la doppia "c").
Che sia perché ricorda un locale che si trova in molte case?
Un commento veramente gratuito!
La pronuncia? Un problema tipicamente italiano, dove ogni minima parola
straniera crea scompensi psicologici non da poco. Vogliamo parlare di come
sento pronunciare Excel? Lasciamo perdere, ho appena mangiato!
Essere parte di un gruppo (Apple lovers), non vuol dire buttare fango su
tutto quello che gruppo non è. Troppo facile: non richiede neanche lo sforzo
di analizzare criticamente!
Mi consola non essere l'unico a pensare che Access sia un
ambiente di programmazione non precisamente fra i più apprezzati.

Per quello che ne so, permette di fare facilmente schifezze
impossibili da creare in altri ambienti. Lo so, perché ho
visto.

Ciao
Enrico
Angelfall
2004-12-14 20:51:07 UTC
Permalink
Post by Enrico Gregorio
Mi consola non essere l'unico a pensare che Access sia un
ambiente di programmazione non precisamente fra i più apprezzati.
Sei anche lunico a pensare che Access sia un ambiente di programmazione.
--
Quando c'era lui i treni partivano in orario
Quando c'era lui ci deportavano in orario
Riccardo Saettone
2004-12-15 11:51:46 UTC
Permalink
Post by Mac dal 1993
Post by Enrico Gregorio
Non conosco Access, ma ho usato, ahimé, programmi prodotti
in tale ambiente di programmazione (?).
Per fortuna non esistono analoghi sistemi nel mondo Mac.
Per fortuna lo dici tu! Perché credi che abbia scritto questo messaggio se
avessi già visto qualcosa anche solo di vagamente simile per il Mac?
Il fatto di essere (orgogliosamente) utenti Mac non ci deve far calare un
velo sugli occhi e riconoscere che su questo fronte siamo carenti.
Uso Access in ufficio e ti assicuro che è un programma tra i più complessi e
articolati tra quelli messi di default.
Visto che anche io uso sia access (tutti i giorni a lavoro) che Filmaker ( a
casa e meno spesso).
Ti do il mio giudizio.
A livello di programmazione nuda e cruda in effetti access e` abbastanza
fornito, nel senso che ti mette a disposizione le funzione base che ti
servono per crare applicazioni anche complesse.
Magari mancano alcuni strumenti per quanto riguarda il debug, ma per contro
e` molto semplice da programmare ed l'autio in linea e` abbatsanza chiaro.


I grossi problemi con Access vengono fuori quando si hanno molte tabelle con
parecchie relazioni e sopratutto quando si cominciano ad avere archivi oltre
i 20 30 mega, in queste condizioni l'eventualita` che il database si corrompa
diviene molto alta, questo almeno nella miea sperienza, e non parlo delle
piccole applicazioni che sviluppo per nostro uso interno, ma di applicazioni
ben piu` grosse e corpose, che si trovano in commercio.
Altro gorsso problema di acesse e l'uso simultaneo da parte di piu` utenti,
sempre riguardo alla mia personale esperienza ti posso dire che quando si
hanno piu di 6o 8 utenti che lo utilizzano contemporaneamente i rischi di
daneggiamenti alla base dati crescono di molto.

Per contro Filmaker ad una interfaccia di programmazione che a me
personalmente e sottolineo A ME, non piace per nulla, e rimasta ancorata a
gli script e da li non si muove, fare il copia ed incolla del codice e`
ancora una utopia, come ad esempio avere una visione totale degli script.
E` pero molto semplice da usare sopratutto per l'utente alle prime armi.

Per contro filemaker ad una motore del databse molto robusto, dove lavoravo
prima avevamo un programma che serviva a gestire i lavori svolti per i
clienti, ed era di oltre 60 mega e veniva usato contempraneamente da 7/8
persone con continue modifiche e cancellazione di dati, e in piu` di un anno
e mezzo di uso non si e` verificato neanche un problema.
e si trattava di una cosa fatta in casa e cresciuta secondo le necessita.
Altro punto di forza di filemaker e la facilita` con cui puo` adare sul web,
o essere usato da piu` persone in rete.
Post by Mac dal 1993
A proposito, Access è inserito nell'Office di Window, mentre il Mac ti mette
al massimo un Outlook rinominandolo Entourage che fa più fine.
Io uso tutti i giorni Entourage di office prima office X ed ora 2004 e ti
posso assicurare che non e` outlook rinominato, ti diro` di piu` enturage su
mac e molto superiore come stabilita` e velocita` ad entourage su XP.

Comunque il problema rimane io ti consiglio di valutare 4D, che tra l'altro
stiamo valutando anche noi per sbarazzarci di access, funziona sia su Mac che
su PC, e` molto solido, si puo` usare senza problemi in rete, ed e`
consultabile anche via web.
Certo e` un costo addizionale, ma personalmente lo trovo un prodotto molto
validoe a seconda delle licenze che si prendono si riescono anche a contenere
i costi.
--
Riccardo Saettone
Per rispondere togliere Alfa e Beta dall'indirizzo
LCP
2004-12-14 12:46:06 UTC
Permalink
Post by Enrico Gregorio
A proposito di Access: dovrebbe essere pronunciato "Aksèss"
ma moltissimi usano pronunciare "Àccess" (con la doppia "c").
Che sia perché ricorda un locale che si trova in molte case?
in tema sul Cess eccoti un'altra perla:
una volta ho conosciuto uno che diceva che Exel significava: Eccellenza
:-)
questo faceve pure dei corsi di computer

LCP


--------------------------------
Inviato via http://arianna.libero.it/usenet/
Davide Cittaro
2004-12-14 13:16:04 UTC
Permalink
Post by Enrico Gregorio
A proposito di Access: dovrebbe essere pronunciato "Aksèss"
ma moltissimi usano pronunciare "Àccess" (con la doppia "c").
Che sia perché ricorda un locale che si trova in molte case?
Per la verita' io pronuncerei 'ascess', solo per i fastidi che ne
derivano dall'uso!
--
Davide Cittaro
Drop WINDOWS if you want to reply
Davide Cittaro
2004-12-14 13:45:33 UTC
Permalink
4D puo' essere una soluzione. Qui da noi sta per sostituire sia access
che filemaker. Non ho idea, pero', di quanto possa costare.

D
Post by Mac dal 1993
Che ne dite?
Ho visto che l'ultima versione di Filmaker è potente, ma è all'altezza di un
Access?
Alternative?
Quanto costano?
Byebye
--------------------------------
Inviato via http://arianna.libero.it/usenet/
--
Davide Cittaro
Drop WINDOWS if you want to reply
SAP
2004-12-14 14:19:15 UTC
Permalink
Post by Davide Cittaro
4D puo' essere una soluzione. Qui da noi sta per sostituire sia access
che filemaker. Non ho idea, pero', di quanto possa costare.
Costare costa, ma e' un buon progotto, molto potente anche se in passato
era poco intuitivo.
--
Giocare col mondo, facendolo a pezzi...
Bambini che il sole, ha ridotto gia'... vecchi.
AndreaA
2004-12-14 14:39:34 UTC
Permalink
Post by SAP
Costare costa, ma e' un buon progotto, molto potente anche se in passato
era poco intuitivo.
Io uso filemaker da una vita, ma la versione 7 mi sta dando parecchi
problemi a livello di formati scheda e stili con il copia incolla.
4D non l' ho mai usato, come funziona?
E' intuitivo come filemaker oppure è come mysql?
--
Ciao Andrea
SAP
2004-12-14 16:07:28 UTC
Permalink
Post by AndreaA
E' intuitivo come filemaker oppure è come mysql?
Un ibrido direi.
--
Giocare col mondo, facendolo a pezzi...
Bambini che il sole, ha ridotto gia'... vecchi.
Riccardo Saettone
2004-12-15 11:53:43 UTC
Permalink
Post by AndreaA
Io uso filemaker da una vita, ma la versione 7 mi sta dando parecchi
problemi a livello di formati scheda e stili con il copia incolla.
4D non l' ho mai usato, come funziona?
E' intuitivo come filemaker oppure è come mysql?
Io ci ho messo le mani solo da pochissimo tempo e proprio per vedere se e`
possibile sostituirlo a acees e filemaker.
Come programmazione mi sembra molto piu` simile a qualle di acess che non al
sistema di script di filemaker.
Certo e` che mette a disposizione un sacco di strumenti, e per fortuna anche
al livello di programmazione.
Il costo a quanto ho capito fino ad ora puo` variare di molto, a seconda di
di cosa una acquista, sia a livvelo di client che di server, che di
"compilatore".
Una cosa di cui mi sto accorgendo e che e` davvero veloce.
--
Riccardo Saettone
Per rispondere togliere Alfa e Beta dall'indirizzo
SAP
2004-12-15 12:02:17 UTC
Permalink
Post by Riccardo Saettone
Una cosa di cui mi sto accorgendo e che e` davvero veloce.
Veloce lo e' sempre stato, e anche potente, dalla versione 6 hanno
migliorato anche l'intuitivita' del programma che prima era un disastro.
E' multipiattaforma e molto solido come progetto venendo da molto
lontano.
--
Giocare col mondo, facendolo a pezzi...
Bambini che il sole, ha ridotto gia'... vecchi.
Salty-Dog
2004-12-15 22:35:31 UTC
Permalink
Post by SAP
Costare costa
Qualche mese fa abbiamo fatto un incontro tecnico su 4D e in quel
periodo ricordo che c'era una offerta molto allettante, tanto che almeno
due dei nostri iscritti l'hanno acquistato (una cosa intorno al
centinaio di Euro). Non è escluso che ricapiti, altrimenti sì,
costicchia.
--
Per contattarmi:
http://formmailto.com/saltydog
fbrzvnrnd
2004-12-14 13:51:00 UTC
Permalink
Post by Mac dal 1993
Che ne dite?
Ho visto che l'ultima versione di Filmaker è potente, ma è all'altezza di un
Access?
Alternative?
io sto sperimentando l'accoppiata neooffice+mysql. costo zero,
interfaccia abbastanza simile ad access.



f.
--
avete mai assaggiato le lame rotanti? http://www.lamerotanti.com
Thomas Picenni
2004-12-15 08:31:00 UTC
Permalink
M
Post by Mac dal 1993
Alternative?
Quanto costano?
Byebye
--------------------------------
Inviato via http://arianna.libero.it/usenet/
IMHO filemaker lo supera access
Pier Paolo Giovannini
2004-12-16 01:58:37 UTC
Permalink
Post by Mac dal 1993
Alternative?
PostgreSQL: http://advocacy.postgresql.org/?lang=it
--
DSS: rtsp://ppg.dyndns.info/classical
Giovanni Mannarino
2004-12-16 07:06:25 UTC
Permalink
Post by Pier Paolo Giovannini
PostgreSQL: http://advocacy.postgresql.org/?lang=it
Esiste una GUI comoda (o, per meglio dire, poco scomoda) come quella di
Access per utilizzarlo su Macintosh? Da questo punto di vista mi sembra
che sia messo meglio MySQL, per il quale hanno sviluppato dei front-end
grafici per MacOS X.
Pier Paolo Giovannini
2004-12-16 22:18:05 UTC
Permalink
Post by Giovanni Mannarino
Esiste una GUI comoda (o, per meglio dire, poco scomoda) come quella
di Access per utilizzarlo su Macintosh?
Access? Non esattamente...

DataWerkz: http://www.uwerkz.com/cgi-bin/page?PAGE=datawerkz.html
--
DSS: rtsp://ppg.dyndns.info/contemporary
Alex Martelli
2004-12-16 07:14:51 UTC
Permalink
Post by Pier Paolo Giovannini
Post by Mac dal 1993
Alternative?
PostgreSQL: http://advocacy.postgresql.org/?lang=it
Ottimo back-end, lo uso davvero molto (sento dire che ora ha superato i
limiti che aveva su Windows, non so, su Mac e altri Unix e` sempre
andato benone). Ma non mi pare che sia accompagnato da nessun sistema
facilitato per sviluppare front-end GUI (o mi sono perso qualche
clamorosa novita`? ho visto che c'e` il RC della 8.0 da un par di
settimane, ma sono stato molto impegnato per provarlo...). Visto che
Access e` appunto un prodotto per fare front-end...


Alex
Pier Paolo Giovannini
2004-12-16 13:43:13 UTC
Permalink
mi sono perso qualche clamorosa novita`?
Marc Liyanage - PostgreSQL - Additional Information:
http://www.entropy.ch/software/macosx/postgresql/#info

Google Search: PostgreSQL gui front-end for "mac os x"
http://shorl.com/fakafruguvudru
--
DSS: rtsp://ppg.dyndns.info/classical
Alex Martelli
2004-12-16 15:04:36 UTC
Permalink
Post by Pier Paolo Giovannini
mi sono perso qualche clamorosa novita`?
http://www.entropy.ch/software/macosx/postgresql/#info
Google Search: PostgreSQL gui front-end for "mac os x"
http://shorl.com/fakafruguvudru
Interessanti misture. Qualcosa di usabile ci sara`, senza dubbio.


Alex
Pier Paolo Giovannini
2004-12-16 22:18:12 UTC
Permalink
Post by Alex Martelli
Qualcosa di usabile ci sara`, senza dubbio.
Infatti, credo ci sia qualcosa di interessante...

DbVisualizer: http://www.minq.se/products/dbvis/
--
DSS: rtsp://ppg.dyndns.info/contemporary
SAP
2004-12-16 14:02:23 UTC
Permalink
Ma non mi pare che sia accompagnato da nessun sistema facilitato per
sviluppare front-end GUI (o mi sono perso qualche clamorosa novita`?
A te come a Giovanni poco sopra: ho chiesto tempo fa' agli sviluppatori
di YourSQL (font-end grafico per MySQL che mi piace molto) se era
possibile introdurre il supporto a PostgreSQL, perche' mi pare che sia
una grave mancanza che potrebbe portare molti nuovi utenti verso questo
buon DB.

Mi sono visto rispondere (in italiano!) dallo sviluppatore principale
(Morten Norby Larsen) del progetto che e' e resta OpenSource (come
CocoaMySQL del resto).
Ma qui ci sono o no dei programmatori? :)

Vi riporto lo scambio di mail (scuserete il mio inglese maccheronico):

-- -- -- -- -- -- -- --
Hi,
Do you have plans to support others SQL DataBase like PostgreSQL (my
favorite ones)? I think that will be a killer application if via JDBC or
other driver, YourSQL will support others DB's. I'm not a programmer and I
can't help you for this kind of implementations, but you have all my moral
support!
Infatti c'e' gia' (di nascosto) un po' di supporto per PostgreSQL (e
MSSQL server). Il problema e' che il primo tab (quello della definizione
delle tabelle) deve essere fatto su misura di ogni database, e non siamo
abbastanza esperti di Postgres per poterlo fare.

Stesso discorso per MSSQL server.

Tanto per dire:

In postgres com'e' che fai a cambiare il tipo di una colonna (da INT a
VARCHAR, per esempio?)

Non ho neanche capito se sarebbe meglio fare una versione a parte
oppure fare YourSQL diventare un programma generico per tanti database?

Ad ogni modo direi che qualcuno deve prendere la cosa in mano - noi
purtroppo non abbiamo le risorse per farlo.

Ciao,

Morten
Fare un client per ogni DB sarebbe dispersivo e introdurrebbe una
molteplicita' di programmi che finirebbe per ingenerare confuzione.
Renderlo "agnostico" al DB sarebbe molto bello, ma sarebbe compito arduo
da implementare dato che molti DB utilizzano estensioni proprietarie SQL.
Io mi fermerei sopratutto ai DB Open Source come MySQL e PostgreSQL. In
particolare Postgres e' su mercato l'unico DB totalmente Open Source che
offre funzionalita' che ancora latitano o sono inesistenti su MySQL come
le Views, le query annidate, stored procedures, triggers, transazioni ACID
(atomiche, Coerenti, Indipendenti, Durevoli), gesione dei dead keys, ecc
ecc. Per progetti di sviluppo client server e' un DB molto usato e senza
alcuna limitazione di licenza, come invece ha MySQL.
Ad ogni modo direi che qualcuno deve prendere la cosa in mano - noi
purtroppo non abbiamo le risorse per farlo.
A questo possiamo porre rimedio in qualche modo, se mi dai
l'autorizzazione a pubblicare la tua mail, posso chiedere l'aiuto alla
comunita' Macintosh all'interno della quale ci sono valenti
programmatori...
-- -- -- -- -- -- -- --

Ora non rimane che sperare che questo appello venga raccolto da
qualcuno.

I progetti per front-end grafici Open Source a cui lavorare non mancano
affatto, i due migliori sono proprio YourSQL (e visto che c'e' un
italiano nel progetto io tifo per quello) o CocoaMySQL.
Basterebbe qualcuno con un po' di buona volonta' e le giuste conoscenze.

Tu o Enrico franchi invece potreste promuovere un qualche progetto
basato su Python e anche questo potrebbe essere qualcosa.

Esistono per la verita' altri fron-end, ma si tratta di oggetti
commerciali di un certo peso...
--
Giocare col mondo, facendolo a pezzi...
Bambini che il sole, ha ridotto gia'... vecchi.
Loading...