Newsgroup: it.comp.appl.access
Titolo: Filemaker vs. Access + SQL Server

Qualcuno di voi hai mai avuto modo di sviluppare un progetto con Filemaker?
In caso affermativo mi piacerebbe sapere con che risultato.
Mi è stato chiesto di sviluppare un progettino con Filemaker 7, ma avendo da
poco terminato un progetto con Access 2003 + MS SQL server 2000, nonostante
le porcate di Access, oramai è un prodotto che conosco abbastanza e dunque
non mi va di ricominciare da capo, a meno che qualcuno di voi che l'ha
provato mi dica che è veramente un bel prodotto che vale pena imparare.
Deve lavorare in cliente/server, multiutente, dai 30.000/ ai 200.000
records, mission critical.
A voi!

 records, mission critical.
Filemaker vs. Access    è la dimostrazione di quanto sia caduta in basso
Microsoft.
FileMaker non ha manco uno straccio di linguaggio di programmazione ... e
c'è chi vorrebbe utilizzarlo per sviluppare applicazioni!!
Piuttosto, non ho ancora utilizzato A '2003: a che porcate ti riferisci?
Matteo

 ha scritto nel messaggio
news:n1WIc.80331$G%.48085@tornado.fastwebnet.it...

A noi che? Di quali porcate parli? La genericità delle tue affermazioni mi induce a
pensare che tu di Access non abbia utilizzato che qualche Wizard, oppure che sei un
troll. Le due cose potrebbero peraltro non escludersi a vicenda, pertanto ti
inserisco nella lista nera.
Galliano.

 inserisco nella lista nera.
Cos'è un troll ? Il cantante del +- famoso complesso ? (New Trolls).
Perdonate la pessima battuta.
In effetti, pur essendo Access perfettibile, il termine "porcate" è 
piuttosto pesante.
Anche la reazione non è molto leggera. 
Sullo specifico un mio (ex) cliente che (anche per colpa mia) ha
rifiutato un'applicazione access afferma che filemaker è impressionante
per facilità, sicurezza, immediatezza .....
Io non l'ho mai visto ma pensavo di dare un'occhiata.
Eventualmente, forse dopo Agosto potro dire di + .
Rimango curioso sul termine troll.
Ciao
Marco
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 ha scritto nel
messaggio
news:543c2671c060101f04b...@mygate.mailgate.org...

Troll = provocatore.
Non c'è paragone tra i due: anche un carro è più
semplice di un'automobile e in alcuni casi più
pratico,
bisogna vedere a cosa ti serve.
MAssimiliano

 MAssimiliano
Hai reso molto bene l'idea.
E hai messo + di 1 dubbio sull'opportunità di vederlo.
Grazie
Ciao


 Eventualmente, forse dopo Agosto potro dire di + .
Tu svilupperesti soluzioni con Access se supportasse solo le "Macro" e non
esistesse Visual Basic?
E non mi riferisco solo alla scarsa flessibilità in fase di programmazione,
ma anche alla pessima gestione delle eccezioni e l'illeggibilità di un
simile sistema di sviluppo.
A parte questa *limitazione* (un edificio senza fondamenta) FileMaker ha
delle caratteristiche bizzarre, forse reminescenze Apple: è pesantissimo a
livello di gestione dell'interfaccia, e viaggia sempre col freno a mano
tirato.
Su qualunque PC tu faccia girare un'applicazione FM, è sempre lenta ... bah,
forse la cosa è voluta.
Altro aspetto insopportabile è l'invasività della GUI di FM: sempre in mezzo
e praticamente inoccultabile.
Il motore Server, tecnicamente parlando, è al passo coi tempi: non
sofisticato come MS SqlSvr ma con elevate possibilità d'archiviazione.
Il problema sta sul lato Client: assolutamente inaccettabile per esigenze <>
da utente finale.
Matteo

 Galliano.
Caro Galliano, la tua (probabile) giovane età ti porta a delle conclusioni a
mio avviso affrettate, e di necessari approfondimenti.
Se dovessi mettermi sul tuo stesso piano, potrei candidamente considerare
l'ipotesi che tu sia prezzolato da Microsoft, ti pare?
Ma cerchiamo di essere seri:  la mia domanda era relativa ad uno schietto
confronto tra i due prodotti citati, ma visto che mi richiami sulle pecche
di Access, benvenga.
Per quel che riguarda i sistemi RAD (dei quali,  a mio modesto avviso,
Access fa parte) la mia precedente esperienza risale a ben dieci anni fa con
un prodotto praticamente morto (Paradox per windows v. 7), che tuttavia per
certi aspetti tutt'ora è superiore al nostro caro Access, il quale, negli
ambienti degli sviluppatori è sempre stato considerato un prodotto limitato.
Tuttavia la mia ingenua speranza è stata (prima di intraprendere lo sviluppo
del progettino Access + SQL Server) che nel frattempo le cose fossero
migliorate, e se questo è vero per certi aspetti, per altri purtroppo non si
può proprio dire altrettanto.
Alcune considerazioni:
-  Un "event model" ASSURDO: Access non gestisce in modo completo gli eventi
dei record in una lista; prova a implementare un "record higlight"......anzi
lascia stare! CENTINAIA di righe di codice che sono state scritte da Stephen
Lebans per risolvere questo limite. E poi Microsoft ha introdotto il
"conditional formatting"...un vero maiale, lentissimo e sopratutto non
funziona! In alcuni casi crea un loop che crasha l'applicazione! Oppure: mai
provato a forzare la chiusura di un form, e a "cancellare" l'uscita nel
BeforeUpdate? L'applicazione esce!! Ti rendi conto?
- Paradox aveva il codice correlato ad ogni singolo oggetto, Access no; se
rinomini un oggeto il codice non funziona più
- Lo scorrimento verticale con le frecce su una lista lo devi gestire da
codice!
- Record locking.....vogliamo parlarne? Se vuoi veramente implementarlo con
tutti i crismi ti tocca progettare un form "unbound" e gestire "a mano" i
blocchi.
-  Access è lento, molto lento
- La qualità di stampa di Access è ignobile, la grafica viene stampata al
massimo a 72DPI, e ho dei report dove a le linee delle griglie (grige) a
volte vengono stampate a volte no (su una stampante laser a 1200DPI).
- La logica che governa i campi calcolati (SUM, etc) è assurda! Forzare
.requery, .refresh, .recalc....evvai!
- Crash inspiegabili dell'applicazione (siamo alla versione 2003 eh?!)
Ora mi fermo per non dilungarmi. Access va benino ma alla MS si poetvano
spremere un pò di più per tirare fuori un prodotto migliore, o quanto meno
in tutti questi anni potevano migliorare delle cose che ancora non
funzionano.


Tu l'hai provato? Che ne pensi?


Dunque l'hai provato?
Il punto è che il mio cliente ha realizzato una decina di form con relativi
archivi, non ottimizzati, non normalizzati, su macchine non connesse in
rete, e vuole continuare ad avere un progetto FM. Convintomi di una sua
presa di posizione, volevo comunque avere un 'idea dei punti di forza e di
debolezza del prodotto.
Nei forum in lingua inglese mi hanno risposto (probabili) consulenti che
usano FM i quali giurano che FM è una ficata, che è velocissimo, più
intuitivo di Access etc etc. Ovvio ognuno tira l'acqua al suo mulino. Volevo
dunque confrontarmi con chi avesse usato tutti e due per avere un giudizio
spassionato

 spassionato
Non sono uno psicoterapeuta: quindi non ho altro da aggiungere a quanto già
scritto.
Fai una cosa: vai su 
http://www.omniagest.it/
 scarica un classico prodotto
FM e fattene un'idea ... poi fai come credi.
Buona parte delle cosucce che scrivi su Access (a partire dalla formatt.
condizionale che non andrebbe) sono problemi che non riscontro, quindi
comincio a credere che tu abbia davvero voglia di trollare.
Matteo

 Matteo
Vabbè, ora dateve un bacetto...
Antonio

 - Crash inspiegabili dell'applicazione (siamo alla versione 2003 eh?!
Finalmente un problema reale.
Ma ti devi rassegnare: tutti i prodotti RAD sono, prima di tutto,
applicazioni sofisticate che di conseguenza hanno un buon numero di bugs.
Per questo voi principianti dovete abituarvi a installare i S.P  (e magari
aspettare a usare un prodotto nuovo prima che ancora sia stato
patchato).
Se la cosa non vi va bene è inutile pensare che da qualche parte del mondo
esista un RAD migliore e "più stabile" o "più veloce" ... dovete
semplicemente tornare a lavorare in COBOL.
Saluti: Oscar

 stampe d'ufficio e non per lavori tipografici.
Si, è ovvio che un prodotto di office automation che sta sul mercato dalla
metà degli anni 90 non stampa correttamente una griglia?
Sei ridicolo!!

 model con i controcoglioni.
Tipo? Fai un esempio?
Senza alcuna polemica, sia chiaro.
Sandro.
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 Sei ridicolo!!
Sei solo un principiante coglione, troll e incapace.
Ma vai a usare FileMaker idiota...
Saluti: Oscar

 Senza alcuna polemica, sia chiaro.
Senza entrare troppo nel dettaglio e nei particolarismi di in Event Model
(sincrono/asincrono,push/pull, ......) tieni presente che ogni event model
(event manager, event service) ha precipui punti di forza e di debolezza,
fortemente dipendenti dal contesto per cui l'EM è stato creato.
Il giusto punto di incontro tra punti di forza e di debolezza rispetto
all'ambito per cui un EM è stato sviluppato ne determinano probabilmente la
superiorità rispetto ad altri.
A mio modesto avviso confrontare gli EM di Java,  .Net, PowerBuilder,
Delphi, oppure di CORBA con quello di Access non ha molto senso.
Mi basta notare che  l'EM di Paradox per Windows  (ormai morto) di dieci
anni fa, seppur più complesso, era superiore di quello di Access di oggi.

 anni fa, seppur più complesso, era superiore di quello di Access di oggi.
Sempre senza polemica (e dimenticando parolacce e apprezzamenti personali)
fai esempi pratici di eventi che non siano assolutamente mappabili con
Access, nemmeno sfruttando l'API con subclassing e amenità varie  (citavi
giustamente Lebans).
Non hai risposto all'atto pratico alla richiesta di Sandro...


Scappo a mangiare, domani ti rispondo.
Ciao

 :) Ora va meglio!
Abbiamo esagerato?
Saluti: Oscar

 ha scritto nel
messaggio
news:1DuJc.82900$G%.62530@tornado.fastwebnet.it...

Ok Access è un merda e COBOL decisamente meglio.
Senti a me, abbandona Access e questo NG
MAssimiliano


Ok! E' esattamente quello che volevo sentir dire in un thread in cui si
parla, forse otremodo animosamente, di eventi ed handler associati.
Lo scenario di riferimento DEVE, e lo urlo, condizionare senz'altro gli
eventi e la gestione che se ne fa.
Mi spiego.
Se ho bisogno di interagire con un sistema real-time (ad esempio un
sequencer audio, o il cruscotto delle telemetrie di un satellite, o fai un
po tu ...) probabilmente andrei in direzione delphi. Ma magari andrei in
direzione di un altro so, magari un sistema operativo costruito attorno ad
un event-model, tipo wxworks o qnx.
Ma per progettare un interfaccia utente che interagisca con un database,
francamente, non andrei a scomodare null'altro che un bel rad potente e
robusto come Access (lasciamo perdere gli aspetti di db management, che non
centrano nulla con l'EM), con tutti i limiti che si porta appresso e che
costringono lo sviluppatore a forzare qua e la (personalmente mooolto di
rado) con le api ed il subclassing.
Dammi retta. Rileggiti la zona di quoting in testa a questo reply, e capirai
di esserti risposto da solo... ;-)
Ciao, Sandro.
