Una volta per tutte una risposta ai detrattori di Access

di il
28 risposte

28 Risposte - Pagina 2

  • Re: Una volta per tutte una risposta ai detrattori di Access

    29/12/2022 - PiGi78 ha scritto:


    Pertanto non possiamo paragonare Access a strumenti/linguaggi/RDBMS più completi (e complessi)… Però non possiamo nemmeno nascondere che per certe piccole applicazioni Access vada benissimo 

    Su questa affermazione potrei anche essere d'accordo, ma è una sintesi ben diversa da quella che viene veicolata invece dal messaggio sottointeso dall'articolo che stiamo commentando.

    E a prescindere da questo, anche per quelle applicazioni per cui Access andrebbe benissimo, a oggi in base alle mie conoscenze suggerirei in ogni caso altri linguaggi e tool che, oltre a coprire quelle necessità specifiche, ne indirizzano potenzialmente molte altre e vanno ben oltre alle potenzialità offerte da Access, a mio giudizio (ma non solo mio) troppo ristrette per soddisfare larga parte delle necessità di uno sviluppatore a oggi, a prescindere che vi possa essere qualcuno che ne tragga benefici per gestionali verticalizzati e clienti specifici, visto che non si sta ragionando in quel contesto, ma in uno molto più ampio nel quale queste ristrettezze non sono fattuali, ma traveggole di presunti “detrattori”.

    Quindi sebbene per certe applicazioni Access vada benissimo, per le premesse di cui sopra e con un'ottica rivolta al futuro, di certo non si può ritenere Access “moderno” così come è stato definito nell'articolo, così come credo sia improprio definire “detrattore” chiunque esponga ed evidenzi dati alla mano (si leggano tutte le mie considerazioni in questo thread) il respiro più ampio che si riesce a ottenere con tanti altri strumenti alternativi ad Access, non perché io abbia in odio questo tool ma perché, per conoscenze e competenze acquisite personalmente, so benissimo che c'è di meglio, molto meglio, in tutti i sensi in cui questa frase può essere intesa, tecnicamente e commercialmente.

    Un conto è parlare di una tecnologia poco conosciuta o emergente che ha delle potenzialità inespresse ma largamente poco note, un conto è parlare di un database che esiste dall'alba dei tempi di Microsoft e che, al netto di qualche restyling applicativo, fondamentalmente è rimasto invariato in un periodo lungo vent'anni e pertanto abbraccia un background che praticamente inizia dal momento della diffusione di massa di Internet e arriva fino ai giorni nostri, senza subire né improvement sostanziali, né migliorie strutturali, e anzi il suo stesso linguaggio e piattaforma (COM/ActiveX) sono fondamentalmente presenti ancora nei sistemi operativi ma di fatto deprecati nel supporto tecnico e negli aggiornamenti (anche di sicurezza) da parte della stessa società che li ha costruiti.

    Puoi dire che volendo, se hai Windows, con Access puoi (ancora per il momento) salvare dati in locale e crearci maschere con una parte di logica per accedervi, ma di certo questo non lo rende una scelta privilegiata né moderna né consigliata, anche se si trattasse di dover suggerire qualcosa a qualcuno che sta per iniziare, in quanto significa investire facilmente in qualcosa di già “superato”.

    Come dicevo, il vero fattore interessante di tutto questo thread in realtà - come diceva anche Oregon - è doversi quasi “sperticare” a citare tutte queste cose per dimostrare ciò che è lapalissiano a una larghissima fetta di sviluppatori software odierni, spiegando quindi i motivi per cui non sono loro a essere “detrattori”, ma banalmente professionisti che valutano un tool per quello che è e quello che offre rispetto alla concorrenza, nulla di più, nulla di meno. :)

  • Re: Una volta per tutte una risposta ai detrattori di Access

    Da amante sfegatato di access, ritengo che sia un po come quelle persone vicine alla pensione che sanno fare di tutto, ma che non eccellono in niente con più la limitazione degli acciacchi dell età. Ottimi per i lavoretti giornalieri, ma che si inchiodano quando occorre professionalità. 

    Con access ci si può fare di tutto, ma per ottenere qualcosa di serio, bisogna usare trucchetti o appoggiarsi a qualche base piu performante. Come ammetti tu stesso, che alla fine usi solo l editor grafico e del vba per i tuoi progetti. Editor inoltre che non sono proprio al top. Anzi tutt altro. La creazione delle maschere è limitata, e scomoda,  i controlli sono privi delle più elementari funzioni al quale ci hanno abituato negli ultimi 30 anni e se le si vuole ricreare bisogna andare giù pesantemente di vba.

    Per non parlare poi dell editor del vba, che è fermo al vb6, quindi a 25 anni fa e sopratutto della gestione delle ribbon dove microsoft non ha nessun editor. Anzi ce l,ha, ma è più agevole scrivere con un pennarello direttamente sul video. Sicuramente i risultati sono migliori.   

    Vedi ad esempio l impossibilità di aggiungere in automatico codice personalizzato alla creazione di una nuova sub. E se la si vuole bisogna pagare 70 euro per un tool di terze parti. Costringendo ogni volta a continui copia incolla, come ad esempio per una gestione degli errori seria che crei un file log degli errori.

    Capisco le poche modifiche al core stesso di access, che ne pregiudicherebbero la compatibilità con databse precedenti wnche vecchi di 20 anni, ma aggiungere funzionalità di sviluppo agevolate, non sarebbe male. Sopratutto per chi usa access in modo serio, o almeno che ci prova a farlo.

    Anche se penso che in italia saranno si e noc5 persone che lo conoscono appieno e sono in grado  di sfruttarlo in modo professionale.

    E comunque da quello che affermi, in realtà non usi access, ma solo il suo editor, quindi ad esempio il delphi lo supera abbondantemente, sia in aspetto grafico che prestazionale. 

    E ripeto. Chi mi tocca access è un uomo morto, però bisogna anche rendersi conto che anche una panda è un auto a tutti gli effetti ma non possiamo fare il confronto con una ferrari. (Ps. Sto spendendo l ira diiddio per ristrutturare una panda 4x4 dell 84, quindi oltre ad access, amo anche le panda) 

  • Re: Una volta per tutte una risposta ai detrattori di Access

    Cerchiamo di circoscrivere meglio la discussione e fare un po il punto.

    La discussione verte su un documento che parla di usare Access come Front-End collegato via ODBC ai principali database server.
    Quindi NON si parla di DB Access su file condiviso (l'ho chiarito bene anche nel messaggio di testa e nel documento originario).

    Questo non vuol dire che si voglia sostenere che è il meglio che c'è, ma che potrebbe essere quello con il miglior rapporto prezzo prestazioni nel contesto dei piccoli gestionali.
    Quindi gestionali con mediamente tre posti di lavoro diciamo fino circa ad una quindicina, in rete locale sotto Windows (lato Client).

    Visto che in vent'anni con Access se ho speso tanto per ambiente di sviluppo mediamente ho speso meno di 100 euro all'anno per produrre ugualmente software che arrivano perfettamente all'obbiettivo in tempi rapidi, non proponete soluzioni che sarebbero costati 1000 euro all'anno, comode per chi fa economie di scala non per un Freelance.

    Delphi, credi che non mi piacesse? (in particolare per un ex programmatore Turbo Pascal).
    Peccato che non costava poco, per la gestione dei reports poi deve appoggiarsi a tools esterni.
    Ora c'è la versione Community … finalmente, ma le limitazioni non sono ancora chiarissime, in particolare quella sui posti di lavoro e poi c'è una limitazione sul fatturato.
    Esistono altre alternative PowerBuilder, C# ed Entity Framework ecc. tutte costose alcune poi richiedono infrastrutture cloud da cui dipendono che in alcuni casi è un vantaggio in altri un limite.

    Quindi proponete infrastrutture che permettano (lavorando bene) di produrre in tempi rapidi risultati di qualità a costi da FreeLance.
    E serve TUTTO (costruzione grafica di Forms, Report, Grafici ecc.) liberamente reinstallabile su più posti di lavoro e che permettano di usare un qualsiasi DB Server tra i principali.

    Quello che conta è la qualità del risultato che si misura in usabilità e stabilita, onestamente il cliente compra e vede quello.

    Il problema non è se con il tuo strumento puoi produrre una porcheria (e con Access ne hanno prodotta tanta perchè tanti ci hanno fatto giochini), ma se lavori bene esplicitando le variabili, strutturando gestendo bene le strutture relazionali ecc. ecc. , se lo strumento ti permette di ottenere buoni risultati rapidamente facilmente gestibili ed a costi bassi.

  • Re: Una volta per tutte una risposta ai detrattori di Access

    Risultati di qualità e tempi rapidi nella stessa frase con la parola access non esiste nel vocabolario.

    Sinceramente non ho ben capito che cosa sviluppi, e che risultati ottieni, ma ho scorso un po le domande che hai posto in questo forum su access e non lo dico per offendere o criticare, ma sono domande su problemi molto basici che si riaolvono o si incontrano nella prima settimana che si inizia ad usare access a livello di vba. 

    Quindi tutto questo arroccarsi sul difendere un prodotto (che amo ed adoro )   che anche se unico nel suo genere, si posiziona su un applicativo scolastico, mi sembra fuori luogo. 

    E comunque ritornando ai costi , è vero, spendi poco, ma anche il prodotto che rivendi costa poco. Se per un applicativo realizzato con access, si chiede piu di 100/200 euro, gia ci si sta approfittando. 

    Comunque in tutta sincerità, da purista ed amatore di access, ti dico che il primo detrattore sei tu, visto che Usi solo l ide grafica.

    Tu non usi access. Ci disegni.

  • Re: Una volta per tutte una risposta ai detrattori di Access

    30/12/2022 - paoloholzl ha scritto:


    La discussione verte su un documento che parla di usare Access come Front-End collegato via ODBC ai principali database server.

    Perfetto. In tal caso, ribadisco il mio parere sul punto della discussione in riferimento all'uso (l'unico) possibile per Access:

    • conosco tool migliori di Access per costruire frontend, molto più produttivi, che permettono di costruire GUI anche complesse (non ci sono solo una decina di componenti tra cui scegliere) con sforzo decisamente minore;
    • i tool in questione usano linguaggi di programmazione più espressivi e più chiari, costantemente aggiornati, che permettono di applicare pattern e metodologie che in Access non sono viabili e che io personalmente considero imprescindibili, a meno che non parliamo di giocattoli;
    • in termini di costi, anche se non sono gratuiti o economici come Access, il costo dei tool è perfettamente ripagato dalla maggiore produttività e dal tempo minore che impiego a realizzare lo stesso software con Access causa le sue limitazioni rispetto ai primi, poiché anche il tempo è denaro, e l'investimento viene ripagato perché posso riutilizzare conoscenze e mezzi anche per tutti gli altri scenari che Access non supporta;
    • ODBC è un protocollo legacy (è del 1992!) ed è troppo lento, o comunque ho alternative migliori di connessione ai principali database server, quali ADO DB o client specifici, e librerie molto più performanti (dbExpress, FireDAC, SQL Native Client …);
    • anche per applicazioni estremamente semplici, non voglio avere una dipendenza da Access come tool né doverlo distribuire né doverlo installare presso i miei clienti;
    • per esigenze che esulano dalle funzioni base di Access o per controlli visuali aggiuntivi a quei pochi presenti di default occorre comunque reperire e/o acquistare componenti di terze parti, che tra l'altro vanno installati (vedi “regsvr32”) e devono essere disponibili sottoforma di COM/ActiveX, sempre più “rari” e non evoluti dai rispettivi vendor, poiché COM/ActiveX è considerata tecnologia “legacy”, come ODBC;
    • non esiste supporto per qualsivoglia tool di versioning del codice sorgente, indispensabile a oggi anche per qualsiasi sviluppatore software freelance che lavora da solo (e che ovviamente voglia definirsi tale, e non un cioccolataio), anche solo per poter ripristinare una versione precedente del software o confrontare il codice a fronte della risoluzione di un bug, o per tante altre occasioni in cui un tool del genere può dare una mano.

    Tutti questi punti sono riferiti al tipo di applicazione che tu hai proposto: anche in questi scenari, per quel che concerne la mia esperienza (che comunque copre più di 25 anni, non ho solo mangiato-bevuto-dormito in questo lungo periodo), conosco tool migliori, sotto tutti i punti di vista, che si tratti del linguaggio, della progettazione grafica, di qualsiasi elemento di Access venga preso in esame.

    Se poi passiamo al valutare gli scenari per i quali mi viene proposto di realizzare un software, Access risulta inapplicabile nella stragrande maggioranza di questi: non supporta il lavoro in team, non supporta versioning, non supporta pattern, non supporta metodologie, non supporta OOP, non supporta cloud, non supporta device mobile, non supporta chiamate a WS o REST, non supporta la totalità delle risorse e dei servizi a cui quotidianamente mi devo interfacciare, non solo io ma la stragrande maggioranza degli sviluppatori odierni.

    In breve, il contesto di Access è sempre quello mono-utente: in un contesto di sviluppo di applicazioni di livello enterprise, che sia per banking, che sia per una catena di gestione documentale o altro, mostra tutte le sue limitazioni (ad esempio, non posso crearci nemmeno dei servizi Windows in background).

    L'unica conclusione quindi che si può trarre è che se sei abbastanza fortunato affinché la tua applicazione debba essere basata sui dati e poco altro, deve avere maschere tradizionali, deve girare solo su Windows, se lavori da solo, se non vuoi usare pattern né testing, se ti limiti a ODBC per la connettività, se non hai bisogno di altri componenti, se… se… se e se… *allora* alla fine Access puoi utilizzarlo. :)

    Ok, questo l'ho compreso, ben venga, ma come dicevo ho alternative migliori e più produttive, quindi non lo uso in nessun caso, né quando può essere applicabile, né quando risulta fuori requisiti.

    In conclusione, non esiste un valido motivo - non dico dieci, ma uno solo, singolo, individuale - che tu possa portare alla mia conoscenza per il quale risulterebbe tecnicamente e commercialmente vantaggioso usare Access al posto dei tool che già utilizzo, a prescindere dal software che dovrei realizzare e anche nel contesto più adatto alle prerogative di Access.

    Non c'è quel motivo, né per me, né per tantissimi altri: non è essere detrattori, è un dato di fatto e (a meno di cambiamenti epocali) al momento incontrovertibile.

    Ciao! :)

  • Re: Una volta per tutte una risposta ai detrattori di Access

    30/12/2022 - Alka ha scritto:


    prerogative di Access.

    Non c'è quel motivo, né per me, né per tantissimi altri: non è essere detrattori, è un dato di fatto e (a meno di cambiamenti epocali) al momento incontrovertibile.

    Parliamoci chiaro. Il vecchio vb6 già dava pane e nocchie all ide di access. 

    Vb.net o visual studio, sono decisamente migliori per sviluppare front end. Sono compilabili, auto installanti, gestiscono multi istanze, non si portano dietro il carrozzone dell iinterprete access o peggio del runtime cCappato che se non riconosce come fonte sicura un db, ti fa bestemmiare in aramaico, sono eseguibili e gestiscono situazioni che con access è impossibile risolvere se non con artefizi degni del gwbasic. 

    Sono pienamente d accordo con quello che hai sempre detto in tutti i tuoi interventi.

  • Re: Una volta per tutte una risposta ai detrattori di Access

    30/12/2022 - fratac ha scritto:


    Comunque in tutta sincerità, da purista ed amatore di access, ti dico che il primo detrattore sei tu, visto che Usi solo l ide grafica.

    Tu non usi access. Ci disegni.

    Se ci mettiamo daccordo una sera ti colleghi a me con Anydesk, ti faccio vedere alcuni ‘disegni’  (magari uno composto di 400 tra forms e subforms), l'invito vale anche per Alka.
    Ne ho tanti da mostrare, potrei cominciare con un DB di tracciamento alimentare con distinta base illimitata, front end Access, nessun componente aggiuntivo, db su MYSQL e SQLServer.

  • Re: Una volta per tutte una risposta ai detrattori di Access

    Discussione interessante. Da quel che leggo ne emerge che:

    - Access non può essere visto da anni come un solo DBMS e non ci sono motivi per dire che se non lo usi come tale, non stai usando Access, quando perfino il nome suggerisce tutt'altro.

    - Va assolutamente svecchiato in tutte le sue funzioni (anche quella di DBMS), altrimenti i casi d'uso rischiano di diventare sempre più ristretti e con meno pretese, dove perfino l'interoperablità con l'ecosistema Microsoft è compromessa. Il fatto che un'azienda sia piccola, non vuol dire che non abbia prospettive di ingrandirsi senza dover rifare tutta la parte informatica, o comunque che voglia continuare ad usare strumenti da anni 2000.

    - VBA è un linguaggio utile per sfruttare le API dei programmi, ma non particolarmente orientato al problemi che quei programmi si prefiggono di affrontare. Ad esempio in ambiente Excel è stato creato il linguaggio apposito per usare lo strumento Power Query.

  • Re: Una volta per tutte una risposta ai detrattori di Access

    30/12/2022 - paoloholzl ha scritto:


    Se ci mettiamo daccordo una sera ti colleghi a me con Anydesk, ti faccio vedere alcuni ‘disegni’  (magari uno composto di 400 tra forms e subforms), l'invito vale anche per Alka.

    Non è il numero delle maschere che fa la complessità del prodotto.

    Ho migrato io stesso un progetto sul Web che era stato realizzato usando Access creando una miriade di maschere, alcune delle quali molto simili tra loro ed evidentemente ottenute tramite copia/incolla.

    Non è il mio modo di sviluppare una GUI: nei miei applicativi, visualmente posso aver bisogno di aprire più copie della stessa identica Form, cosa che in VBA/VB6 non è possibile fare, poiché la FormX è sia la classe che l'istanza della finestra, ossia non vi è distinzione tra i due concetti.

    Nel gestionale che ho creato con Delphi (ma è possibile anche in WinForms con Visual Studio) ho creato classi per maschere di base da cui ho ereditato finestre discendenti fattorizzando il codice e creando via via finestre sempre più specializzate partendo da una finestra vuota e aggiungendo funzionalità nella gerarchia, creando contemporaneamente l'applicativo ma anche un framework dal quale è possibile creare nuove maschere “ereditando” da una esistente e scegliendo quindi il punto di partenza adatto allo scopo (maschera vuota, maschera per i dati, dialog).

    La flessibilità data dall'IDE, dal linguaggio e dalla libreria di componenti (più di 300 pronti all'uso a nel caso della VCL!) credo non sia nemmeno paragonabile a quella di Access, tanto è siderale la distanza tra le implementazioni tecniche dei due ambienti.

    Non è osservando un progetto da 400 maschere grigie ottenute da wizard e copia/incolla ancorate a tabelle che fa la differenza: parliamo di progettazione e sviluppo del software, parliamo delle sue funzionalità e delle modalità con cui si possono realizzare, parliamo dell'interoperabilità con il resto del mondo, e non di quante finestre possono stare dentro a un database.

  • Re: Una volta per tutte una risposta ai detrattori di Access

    [ot] direi che non è una discussione interessante ma una serie di ovvietà (ben spiegate da alka con infinita pazienza) contro un muro di gomma che non confuta in modo convincente nessun punto che dicasi uno [/ot]

    Non capisco che differenza ci sia nel fare una interfaccia con vb6 (o anche vb5) con cui usare Oracle al posto di Access … boh

    Il fatto che ci sia di mezzo COM/Ole con relativi Activex dimostra anche che andrà tuto a morire e che in MS non c'è nessuno che pensa lontanamente a portare tutto su Linux (al contrario di come è avvenuto per SQL Server) 

  • Re: Una volta per tutte una risposta ai detrattori di Access

    30/12/2022 - Alka ha scritto:


    30/12/2022 - paoloholzl ha scritto:


    Se ci mettiamo daccordo una sera ti colleghi a me con Anydesk, ti faccio vedere alcuni ‘disegni’  (magari uno composto di 400 tra forms e subforms), l'invito vale anche per Alka.

    Non è il numero delle maschere che fa la complessità del prodotto.

    Ma ci mancherebbe. 
    Era solo un modo per rispondere a chi diceva che ci faccio solo i ‘disegni’.
    Se uno ha visto solo dei programmini del cavolo (che con Access pullulano) era un modo per dire con il solo Access ed un DB Server dall'altra parte puoi avere prodotti ben ingenierizzati che fanno quello che al cliente occorre anche con un prodotto datato (purchè ancora supportato).
    E che non lo uso per giocare, visto che ho aziende che lo usano da decenni su progetti di una certa consistenza senza rallentamenti o instabilità.

    Quanto a quello che dici sui form, tutto vero, io li apro in modo parametrico e a seconda del contesto mostro o nascondo gli oggetti.
    Per cui la gestione dei form di Delphi (a 32 bit mentre io lavoro a 64), sicuramente più furba e potente di quelli di Access, non mi avrebbe agevolato più di tanto.

  • Re: Una volta per tutte una risposta ai detrattori di Access

    30/12/2022 - paoloholzl ha scritto:


    Se uno ha visto solo dei programmini del cavolo (che con Access pullulano) era un modo per dire con il solo Access ed un DB Server dall'altra parte puoi avere prodotti ben ingenierizzati che fanno quello che al cliente occorre anche con un prodotto datato (purchè ancora supportato).

    No, ho visto software in Access che gestivano l'intero workflow di un'azienda logistica di trasporti, quindi capisco bene di quali applicazioni stiamo parlando, e di quante e quali maschere possono esserci e della complessità che può esserci dietro.

    Detto questo, sono software che possono essere ben ingegnerizzati solo nella testa di chi li ha creati, perché il linguaggio VBA è limitato: è un software “ben progettato” quello che fa uso di Design Pattern riconoscibili, che rispecchia i principi SOLID, che soddisfa criteri di Clean Code, che si attiene brevemente a tutte quelle norme e prassi ormai consolidate nello sviluppo del software, non da ieri bensì da decenni, anche per lo sviluppo di quel tipo verticalizzato di applicazioni.

    In assenza di queste pratiche, quel codice è “ben ingegnerizzato” solo agli occhi di chi lo ha scritto in quanto, essendo l'autore, ha l'impressione che esso sia comprensibile e il più lineare possibile del mondo, quando le caratteristiche di un codice simile sono in realtà ben diverse e aderenti ad altri canoni e standard qualitativi globalmente diffusi, documentati, condivisi e tangibili, totalmente inapplicabili al codice scritto in VBA (o in VB6), che diventano solo e soltanto istruzioni in risposta a eventi, no more no less.

    30/12/2022 - paoloholzl ha scritto:


    E che non lo uso per giocare, visto che ho aziende che lo usano da decenni su progetti di una certa consistenza senza rallentamenti o instabilità.

    Di nuovo, non ci sono rallentamenti o instabilità perché non esiste un percorso evolutivo di quel software: ci si accontenta che sia in Access o altra base dati, si utilizzano ripetutamente le stesse maschere, non si richiede di accedere all'applicativo in altri modi che non sia RDP, non si adottano strumenti che fanno parte di altri sistemi non Microsoft, non nascono in breve negli anni necessità particolari che richiedano di mettere mano a quanto è già stato codificato.

    Se il tuo parco clienti è tutto così, da un certo punto di vista ritengo tu sia fortunato, poiché puoi portare a casa il grano senza dover fare sforzi particolari aggiuntivi, e avendo tu detto che qualunque richiesta esuli dalle possibilità di Access verrebbe “cassata”, se non te la chiedono ti va già grassa così e, come dire, invidio la tua fortuna.

    Io di clienti di questo tipo io ne ho zero: mi chiedono di non usare RDP ma di accedere via Web, mi chiedono di mettere in mobilità i dati, mi chiedono applicazioni mobile, mi chiedono REST API per poter accedere in sicurezza ai dati senza dover esporre il DB sul Web, mi chiedono servizi in background per produrre reportistica offline e gestire degli alert o l'invio schedulato di e-mail, mi chiedono che il loro software rimanga al passo con i tempi, e come me tutte le software house e gli sviluppatori si trovano grossomodo nella stessa situazione.

    30/12/2022 - paoloholzl ha scritto:


    Quanto a quello che dici sui form, tutto vero, io li apro in modo parametrico e a seconda del contesto mostro o nascondo gli oggetti.

    Perfetto, io non devo basarmi sul contesto, non devo scrivere codice per mostrare/nascondere oggetti, lavoro in un modo che è anni luce distante da quello che VBA mi imporrebbe di fare, che non è prerogativa solo del mio ambiente di sviluppo favorito, ma di qualsiasi ambiente di sviluppo odierno.

    E' fondamentalmente il concetto che si sta continuando a ripetere più o meno dall'inizio: se ti piace fare la panna montana a mano, nessuno di noi vuole toglierti il piacere assoluto di farlo, e se i tuoi clienti sono contenti del tuo lavoro, tanto meglio… ma esiste chi ha un ristorante o fa il catering, con più clienti o clienti più esigenti, nel senso che vogliono il lavoro in tempo minore, o lo vogliono più preciso e regolare sulle quantità a parità di richieste, e fortuna vuole che oltre alla frusta manuale esistano anche le planetarie… certo, tu puoi dire di aver comprato una frusta a 200 euro e con quella ci lavori tutti gli anni, ma non puoi nascondere o eludere il fatto che una planetaria, sebbene più costosa, possa risultare più performante, efficiente e accurata nello svolgimento dello stesso lavoro, riuscendo così a soddisfare una più ampia gamma di esigenze (che siano tempistiche, cura, riproducibilità del risultato, quello che vuoi) e di fatto recuperando sia il costo dell'investimento fatto nell'acquisto della planetaria, sia costituendo un guadagno addirittura superiore rispetto a quello ottenibile montando la panna a mano con la frusta. Se vuoi montare la panna a mano e continuare a farlo, nessuno dice che tu non possa riuscirci, né che i tuoi clienti non debbano essere soddisfatti, e nessuno mette in dubbio che tu abbia vent'anni di esperienza alle spalle di panna montata a regola d'arte che ha soddisfatto la tua clientela e continua a farlo, ma nel campo della ristorazione e della pasticceria, chi eccelle e vuole garanzie o si trova a fronteggiare sfide ben più ampie, necessariamente *deve* usare la planetaria, e dei due strumenti senz'altro quest'ultimo è quello “moderno”, non il primo.

    Ecco, nella metafora Access è la frusta a mano, tutto il resto è la planetaria.

    30/12/2022 - paoloholzl ha scritto:


    Per cui la gestione dei form di Delphi (a 32 bit mentre io lavoro a 64), sicuramente più furba e potente di quelli di Access, non mi avrebbe agevolato più di tanto.

    Delphi (ad esempio) lavora a 32 bit e a 64 bit, non solo su Windows ma anche su Mac, su Android e su iOS.

    Tu dici “non mi avrebbe agevolato più di tanto”, ma è un parere che non posso raccogliere come valido perché, banalmente, tu lo dici ma non puoi saperlo, e lo dici a me che conosco invece entrambi e ho basato proprio su questo aspetto la scelta, quindi lo so e anche benissimo (e mi ritengo fortunato in questo). :)

  • Re: Una volta per tutte una risposta ai detrattori di Access

    Evito di rispondere a discussioni polemiche di ‘celodurismo’ o il mio fa questo e non quello lo fai in modo vecchio ecc.
    Non ho mai scritto che Access sia un ambiente più innovativo di altri e che abbia tutto quello che serve per esigenze non gestionali stand-alone, ci mancherebbe.
    L'articolo che ho volutamente scritto in tono volutamente ‘stimolatore’, ha permesso di ottenere due risposte che mi interessavano che posterò alla fine.

    La premessa, sono anziano e probabilmente anche arteriosclerotico, lavoro ininterrottamente in informatica dal 1985.
    Ho rifatto tanti programmi ‘arenati’ ma non per capacità dei programmatori, ma per analisi totalmente scazzate.
    Negli anni ho lavoravo in GWBasic, Fortran, Cobol, Turbo Pascal, PL1, DB3, Access, RPG, PHP, ASP e su DB Ingres, Informix, Oracle, SQL Server, Mysql, PostgreSQL. Lavorato su Vax Digital, IBM 3090,in SCO Unix, poi sono passato sui PC principalmente nelle varie versioni Win, ed in seguito Linux. Senza contare altri linguaggi spot per programmare etichettatrici, plotter ecc. ZPL, HPGL ecc. ecc.
    E' normale nel tempo diventare ‘poliglotti’, poi se un linguaggio non lo usi più da anni dovresti ristudiarlo da capo, soprattutto se sono linguaggi vivi.
    Però le logiche di codifica restano quelle, si aggiungono tipi oggetti classi, ereditarietà ecc. e altre specificità dei vari linguaggi.

    Questo non è per 'vantarsi' anche perchè molti di questi linguaggi sono morti, perchè quello che conta non è quello che sei stato ma quello che sai fare oggi (tranne il fatto che su progetti molto vecchi siamo in pochi rimasti a saperci lavorare).
    Se vedi il gestionale che gira nella tua banca potrebbe essere ancora in COBOL. Dal tuo punto di vista sono dei cretini a usare un linguaggio del genere, ma magari è un programma più affidabile e meglio ingenierizzato da quello scritto ieri in Java per cui vivrà fino a che sarà manutenibile.

    Progetti stabili e funzionanti, soprattutto quando hanno richiesto tempi lunghi per lo sviluppo, si portano avanti finchè possibile e finchè funzionano.
    Al limite puoi far nascere un progetto parallelo, ma sono progetti costosissimi che spesso finiscono male (anche per la sottovalutazione della complessità del progetto originario).

    Dei linguaggi che ho usato io (con tutti i suoi limiti) il più longevo è stato senza dubbio Access ecco perchè tanti programmi sono attivi e lavorano perfettamente e continuo a manutenerli (e ho speso decisamente poco nel comprare strumenti), il più vecchio credo lavori dal 1995.
    Per carità non hai il versioning, ma se lavori da solo magari ogni volta che cominci una sessione di lavoro ti fai una copia storica, non è uguale ma può bastare. Non ha lo sviluppo comunitario? Chi se ne frega lavoro da solo.

    Ed ora veniamo a quello che mi interessa di più:
    Lo so bene che oggi esistono altri strumenti che conosco solo per sentito parlare e qualche approfondimento, dato che ho quasi 60 anni penso il prossimo potrebbe essere l'ultimo linguaggio nuovo che andrò a studiare (certamente non per rifare i programmi già esistenti e stabili).
    Ma dato che ho speso negli anni anche tempo a studiare linguaggi naufragati (ad esempio ADA e Lisp) , spero che questo nuovo linguaggio mi accompagni nei prossimi anni, vorrei avesse queste caratteristiche che Access mi offriva, tutto ciò che in più ci troverò in più ben venga:

    Permettermi di sviluppare in modo RAD progetti gestionali completi ‘stand alone’ come ho potuto fare fino ad oggi, con Access in pratica disegnare Forms, Report, possibilmente con strumenti Open Source, sempre che questo non mi comporti particolari rinunce e senza costi eccessivi.
    I tempi per un passaggio del genere sono maturi perchè oggi finalmente sembra che qualcosa ci sia, non perchè prima non ci fosse, semplicemente perchè non esistevano versioni ‘Community’ ed erano soluzioni costose.

    Una soluzione è stata proposta qui un altra è emersa in altri forum:

    Delphi rimane il dubbio per i report ma sembrano esserci tools in grado di sopperire, ma la verisone community ha dei limiti non funzionali ma di licenza, il più limitante sembra quello sul numero di posti di lavoro.

    Lazarus, (declinazione Open Source di Delphi) ha di buono che è Open Source ma anche lì si ripropone il problema dei report.
    Bisogna vedere che cosa usare che mantenga la possibilità del Cross Platform.

    Nel mondo Closed:
    C# ed Entity Framework ASP.NET core e per lo sviluppo delle interfacce web Razor ed integrare pacchetti NuGet.
    Oggi in versione Community ha dei limiti che ben si adatterebbero.

    Certamente chi li conosce bene ha buoni consigli da dare.
    Voi che scelta fareste?

  • Re: Una volta per tutte una risposta ai detrattori di Access

    Chiudo questo thread e ho cancellato gli ultimi interventi.

    In questo forum i flames non sono accettabili.

    Buon anno a tutti!

Devi accedere o registrarti per scrivere nel forum
28 risposte