Newsgroup: it.comp.appl.access
Titolo: OT: Un parere da chi ne sa molto più di me

Buongiorno a tutti,
chiedo un vostro parere su di una società da cui abbiamo acquistato un gestionale e-commerce. Molte volte mi avete visto qui fare richieste per superare i limiti di questo software e devo ringraziarvi veramente tantissimo, i vari @Alex, Karl, Bruno e molti altri...in tanti mi avete aiutato fornendomi preziosi consigli che mi hanno aiutato moltissimo a superare gli ostacoli oltre ad aver contribuito alla mia crescita sulla programmazione con Access. 
Adesso, senza far nomi di società e di software, vi chiedo un parere. Il gestionale in questione non ha un blocco di modifica record se due operatori stanno lavorando sullo stesso record e, purtroppo, succede spesso che siamo almeno in due a lavorarci inconsapevolmente, col risultato che alla chiusura della maschera riceviamo un messaggio che ci avverte che l'utente xy ha modificato o sta modificando lo stesso record. Il risultato è che non sapendo chi lo ha aperto per primo, chiudiamo il record e perdiamo i dati della modifica. Ho scritto alla società chiedendo quale impostazione nelle opzioni fosse necessaria per impedire che ciò avvenga, la risposta è stata "Il programma non può effettuare questo tipo di controllo automaticamente.
Dovete organizzarvi a monte, per non lavorare in contemporanea sugli stessi documenti". Ora, dato che non voglio litigare con il programmatore, vi chiedo, sono io che penso che sia una cosa assurda (per non essere volgare) che un gestionale, multiutente, non preveda una situazione del genere e che non abbia delle funzioni di controllo? E poi, cosa vuol dire "organizzarvi a monte", lavoriamo in desktop remoto, ogni volta che apro un qualsiasi record devo telefonare a tutti i colleghi per avvisarli??? Non so voi, ma io trova pazzesca una roba del genere.
Ringrazio sin d'ora chiunque vorrà dire la propria.
Ciao
 
Alfio


perdonami ma fa ridere una risposta del genere, spero non lo abbiate gia 
pagato il software
 
blocchi, transazioni e log proprio per evitare il problema che esponi 
qui sopra sono la base della programmazione multi-utente.
 
parlando di e-commerce credo si parli di mysql giusto?
se si...si possono bloccare i dati sia a livello di tabella che a 
livello di riga e ovviamente gestire le transazioni più o meno come in 
access
ovviamente però vanno gestisti e non sperare che due utenti non lavorino 
mai nello stesso record o che uno venga modificato nel bel mezzo di una 
batch di istruzioni eseguite da un altro utente.
 
link di questa azienda/applicativo che son curioso
 
 
BFS
 
 
 
 
 
 
 
 
 
 

Il 12/02/2021 17:57, Alfio ha scritto:

Ciao, la risposta alla tua domanda e' da un lato semplice e per altro 
verso complessa
E' semplice nel senso che il sistema fornito deve soddisfare i requisiti 
come da accordi, se non lo fa allora avete motivo di rivalervi come 
riterrete opportuno
La complessita' sta nel capire se ci siano stati accordi preliminari e 
di che tipo, e tutto li il problema
Ed anche supponendo ci siano stati precisi accordi, spesso la 
definizione di una funzionalita' puo' essere eseguita in molti modi, 
spesso non vengono menzionati i tempi massimi 'sopportabili', insomma ci 
sono un miliardo di possibilita' che, se gli accordi iniziali non li ha 
fatti un informatico di professione e pure in gamba, potrebbero rendere 
il sistema fornito 'conforme agli accordi' ma comunque complesivamente 
inadatto nel risolvere i problemi del committente
Nella tua descrizione hai usato la parola 'gestionale multiutente', e 
questo mi fa pensare che possa essere usato da piu' postazioni lavoro 
con la sicurezza che esistano meccanismi di blocco di un qualche tipo 
sul record/pagina in editing per evitare problemi legati all'accesso 
concorrente sui dati
Pero' dal "mi fa pensare a.." a dire "deve essere cosi e cosa' "  ce ne 
passa
Just my 2cent
 
 

Alfio expressed precisely :

Se il tuo gestionale fosse in Access...
 
Bruno

 Bruno
Il database lo è...e aggiungo, per fortuna, perché così ho potuto sopperire a tante di quelle cose che non ha...
 
Alfio

 BFS
In privato ti darei le info, ma qui non credo sia corretto, stiamo ancora lavorando con questo software e cambiare nuovamente gestionale dopo solo 2 anni comporta tanti e tali di quei problemi che al solo pensarci rabbrividisco. Il problema è che finché non inizi ad utilizzarlo seriamente non ti rendi conto di quello che in effetti è, come funziona, cosa manca...ci devi sbattere la testa. Mi ero informato con altre aziende che lo usano e tutti a parlarne un gran bene, ma così non è. Pensa che non si può neanche modificare la risoluzione, il tutto è concepito con una risoluzione 800x600, non modificabile, puoi solo portarla a tutto schermo... potessi tornare indietro...
 
Alfio

Non mi permetto di dare giudizi sull'operato altrui senza
 conoscere bene il merito.
 
Il problema che esponi tuttavia è molto meno banale di quanto sembri...
 
Va distinto l'aspetto dati da quello di interfaccia.
Sui dati, a quanto pare, attua un blocco ottimistico dei dati cosa
 che in tanti fanno... 
Applicare in blocco pessimistico sarebbe sicuramente più di aiuto
 ai fini della segnalazione lato Client... ma dubito che
 concretamente poi si riesca a lavorare.
Il blocco del singolo record... non l'ho mai usato quindi ascolto
 esperienza altrui.
Di fatto con access lavorando con maschere associate temo che
 concretamente ci sia poco di realmente funzionale sul feedback
 all'operatore... lavorando tutto in unbound se ne può parlare...
 ma ne vale la pena...?
 
In ogni caso è da distinguere la gestione lato db dalla
 diagnostica lato client... quella che avvisa l'utente che quel
 record è bloccato... per non perdere tempo.
Chiaramente se blocchiamo l'intero recordset beh penso non sia una
 gran soluzione...
 
Access mostra il divieto di accesso nelle maschere continue quando
 il record è bloccato... ma non è una proprietà leggibile e, per
 quanto mi sia capitato ho avuto difficoltà a replicarne la
 funzionalità vera.
 
Transazioni.
Operano lato Engine quindi solo al tentativo di modifica... che
 per chi lavora equivale a quello che dici.
 
Ovviamente ha il vantaggio che sai se hai salvato o meno... ma il
 tempo che hai dedicato a lavorare su un record in modifica che
 poi non hai salvato credo sia il vero problema.
 
La proprietà updatable In qualche modo aiuta... ma...
 
Io francamente sono scettico ci sia una soluzione che accontenti
 tutti gli aspetti in particolare lato Client in modo preventivo e
 funzionale senza ricorrere, ad accorgimenti complessi come fanno
 con dei campi Bit di inibizione nelle tabelle...
 
Non aggiungo altro, leggo interessato se ci sono argomentazioni
 tecniche concrete perché è un ottimo tema.
 
-- 
@Alex
 
 
----Android NewsGroup Reader----
https://piaohong.s3-us-west-2.amazonaws.com/usenet/index.html
 

Senza dubbio Alex,
l'aspetto grafico era solo un'aggiunta alle considerazioni, cosa che comunque avevo notato sin dall'inizio ma mi dicevo che non era importante tanto quanto la funzionalità del software.
Il problema era ed è questa funzione, se il record è in fase di modifica da parte di qualche altro user te lo debba segnalare prima che tu possa iniziare a fare qualsiasi cosa, tutto qui, penso sia fondamentale.
Ma come si può ricevere una risposta del genere? "Mettetevi d'accordo..." ci dotiamo di un elimina code? Prendiamo il numerino e al nostro turno scateniamo l'inferno?
Non so con quale aggettivo definire queste risposta.
 
Alfio

Alfio non entro in questioni che non hanno nulla di tecnico... ma
 più "personale".
 
Detto questo non è questione di grafica... la segnalazione
 preventiva è il vero problema che ho sollevato... che reputo meno
 banale di quanto può apparire, e proprio su questo, ascolto chi
 si è gia espresso con idee più chiare delle mie.


Il 12/02/2021 17:57, Alfio ha scritto:

Spero scuserai l'innioranzia, ma cos'e un "gestionale ecommerce" ?
 

Alfio wrote on 13-02-21 :

E allora te la cavi con poco.
Da Form Contabilità in modalità Design --> Data, l'ultima
proprietà che trovi è Record Locks posta a No Locks: ponila
a Edited Records in ambedue i FE.
Non ti sto a raccontare come funzione perché è più semplice
fare esperimenti e prenderci la mano.
Ma funziona.
 
Bruno

RobertoA brought next idea :

Ma sei proprio innnnniorante!
Sarà un gestionale con particolari funzionalità per l'e-commerce.
lol lol lol
 
Bruno

Innioranza perdonata :)
 
allora, forse avrò utilizzato un termine improprio. Dunque, contabilità, magazzino, agenti, creazione e gestione inserzioni ebay, amazon ecc ecc. ecc
 
Alfio

 Bruno
Eccolo la il solito Bruno... perspicevole.... :)))
 
Alfio


No, "particolari funzionalita" non e' risposta accettabile, allora e' un 
gestionale normale con qualche routine per esportare/importare dati
Speravo mi rispondesse, "e' un gestionale ed anche sistema ecommerce"
Perche' allora partivo con la raffica di domande

 Perche' allora partivo con la raffica di domande
 
E' quello che ho scritto prima, un gestionale ed un sistema ecommerce

Alfio approfondisci sempre quello che ti viene suggerito... perché
 devi capire da solo l'aspetto tecnico.
Se imposti nessun blocco... che poi corrisponde al default Blocco
 Ottimistico, accade proprio quello che lamenti del gestionale
 attuale.
 
Saluti


Alfio formulated the question :

Intanto quel "la" vuole l'accento poi "perspicevole"
non esiste in alcun dizionario della lingua italiana.
 
Beh se sai usare un gestionale multiutenza in Access
come sai usare la lingua italiana...
 
Bruno

 Perche' allora partivo con la raffica di domande
 
Adesso che l'OP ti ha spiegato esattamente di che si tratta,
perché non parti con la raffica di domande?
 
Ma tu poi cosa sai di contabilità? ne hai mai tenuta una?
 
Bruno


Cheee neeee so io di contabilitaaaaa' ?
Niente, perche lo chiedi?
La curiosita' che ho espresso prima consisteva nel credere che un unico 
sistema permettesse di avere le principali funzionalita' dei classici 
gestionali, magazzino, vendite, acqusti, contabilita'...    E   facesse 
anche da e-commerce, e quindi 'rispondesse' alle richieste da esterno 
preparando al volo le schermate in base alle informazioni contenute nel 
gestionale, pagamenti online, e robe cosi'
Ed in quel caso sarei stato curioso di capire come e' strutturato il 
progetto e tecnicamente la parte e-commercio come sia stata realizzata 
(php, asp, asp-net, tipo web server, ecc...)
 
 
 

 Intanto quel "la" vuole l'accento poi 
Giusto!
 
"perspicevole" 
 
era ironico, come "inniorante"...
 
Saluti

Sinceramente non ti seguo,
il software che utilizziamo in azienda è un software acquistato...
Io non ho impostato alcun blocco, ho posto la domanda alla software house, per quale motivo non fosse implementato un controllo circa le modifiche dei record se questi stanno già subendo una modifica da parte di un altro utente...
 
Ciao

Temo che stia sfuggendo il focus sulla domanda posta.
La domanda iniziale era rivolta a capire se, secondo chi crea software per mestiere, se è normale o meno che un programma, multiutente, permetta a chiunque di effettuare modifiche per poi, alla fine, quando dovresti salvare, ti dice che non è possibile poiché l'utente xy sta effettuando modifiche sulle stesso record... spero di essere stato "chiarevole" :)
 
Saluti

 (php, asp, asp-net, tipo web server, ecc...)
 
In quale cavolo di linguaggio sia realizzato un "progetto" e' ininfluente.
 
La penna e' sul tavolo
The pen is on the table
 
Due linguaggi che dicono la stessa cosa
 
La parte e-commerce e' appunto parte.
Un oggetto, in genere, e' , dicono i colti, self-contained
Vari oggetti possono poi comunicare fra loro.
O un oggetto puo essere contenuto in altro oggetto.
 
Una procedura di contabilita' qualsiasi, con le dovute interfacce,
puo' sparare i razzi sulla Luna o su alfa Cygni o provvedere alla
sequenziazione di tutte le varianti di covid-19
L'importate e' che  quei dati siano poi riportati inn partita doppia.
Dove e' il prolema? Esiste il problema?
 
-- 
ac (y-1=x)


Il problema non e' mai lato gestionale
Ma spesso e' lato ecommerce, nel senso che quasi sempre si usano sistemi 
gia' pronti e funzionanti tipo Magento, Prestashop, Shopify, 
NopCommerce, et similia, facendoli comunicare col gestionale
Ed e' proprio su quel 'facendoli comunicare' che spesso casca l'asino 
nel senso che non tutti gli archivi ecommerce si possono andare a 
modificare, oppure la comunicazione non e' in real-time ma diferita per 
diverse volte al giorno oppure il plugin per le statistiche non fa 
esattamente quello che vorremmo oppure ...
Insomma l'integrazione tra sistema informatico aziendale e sistema 
ecommerce non sempre fila liscia come ci si attenderebbe

 ha scritto:r
 
Roberto se l'applicativo non fosse Desk, ma web Oriented... il
 problema sarebbe l'aspettativa di Alfio... per come normalmente
 vengono gestiti gli accessi da web... salvo integrare notifiche
 push per la contemporaneità... ma francamente mai sentito... si
 blocca il record ma tutto è servirsene in quel caso.
 
Per come si è espresso Alfio deve perforza essere applicativo Desk.



Facci sapere
Che questa e' interessante

Alfio laid this down on his screen :

Contabilità, magazzino, agenti, l'emissione e ricevimento fatture
via SDI e successiva automatica registrazione in PD l'hai solo
dimenticato... spero, gestione ammortamenti, estratti conto,
bilancio XBRL, etc sono i componenti principali di un gestionale
moderno.
Ebay, Amazon et similia sono i bells and whistles natalizi.
 
Bruno

Ciao Bruno, ma ti ha preso un po' di "trollite" acuta? 
Dato che non stiamo facendo paragoni con altri software su cosa faccia o non faccia, mi sono limitato a scrivere "contabilità" poiché, la domanda, concerne un controllo che secondo il mio modestissimo parere dovrebbe esserci, se non ricordi di quale controllo parlo puoi leggerlo all'inizio della discussione.
 
Con sconfinata simpatia...
Alfio

 Con sconfinata simpatia...
Grazie, altrettanta!
 
Bruno

 locale più computer e farò le varie prove.
 
Allora: 3 PC, 2 con FE, 1 (il server) con BE.
- Record Locks di una scheda di contabilità (Prima Nota)
  posto a Edited Record in entrambi i FE.
  Se un FE HA INIZIATO l'Editing di un record, quel record
  è accessibile ma non editabile dall'altro FE.
  Nessun messaggio di comunicazione.
  Eseguito l'Editing (AfterUpdate) l'altro FE può a sua volta
  editarlo.
 
- Record Locks posto a All Records per ambedue i FE:
  Se una scheda è APERTA da un FE, l'altro non può aprirla e
  appare il messaggio "Operation must use un updatable query".
 
Quindi poche comunicazioni: una sola e sibillina.
Mi sembrava che in precedenti versioni Access fosse più
ciarliero al riguardo, però potrei sbagliarmi.
 
Comunque, acquisite le modalità di funzionamento, l'operatività
mi sembra accettbile.
 
Bruno

>Comunque, acquisite le modalità di >funzionamento, l'operativitàmi >sembra accettbile.Bruno
 
 
Salvo che così lavora 1 solo e tutti gli altri aspettano... sempre
 che questo salvi ed esca dall'editing.
Deve essere un sistema nuovo di gestire la multiutenza... chissà
 se è davvero accettabile...
 
CVD


 CVD
 
Sul record "under editing" lavora uno solo - come è giusto che sia -
Gli altri possono fare i loro comodi su altri record.
O tu vuoi fare l'ipotesi che altri 50 vogliano contemporaneamente
lavorare su quel determinato record?
 
O pensi che il tuo prossimo sia così simile a te da scegliere,
senza uno specifico e raro motivo, dalla modalità Record Locks
quella All Records che blocca addirittura l'apertura della
scheda se altri vi sta editando un record?
 
Facciamo un patto: tu non ti riferisci mai più a me ed io altrettanto
faccio con te.
Io comunque lo farò da questo momento.
Così evito la tentazione di darti della testa di cazzo tutte le volte
che apri bocca.
 
Bruno

Il problema è tuo non mio... quando sento cose sbagliate intervengo.
 
Ti suggerirei però di fare qualche prova in più cambiando record
 mentre uno edita il primo l'altro edita il secondo... con
 impostato il blocco come dicevi tu.
 
Magari, succede che tutto il recordset è bloccato... oppure il
 blocco pessimistica tu dici che funziona diversamente...?
 
Intanto leggi quello che dice MS:
https://support.microsoft.com/it-it/office/propriet%C3%A0-recordlo
 
cks-6ca29bbb-8824-4671-8087-97fe0568019a
 
Siccome suggerivi questo è MS dice il contrario magari hai qualche
 osservazione tecnica più avanzata...
 
Se non riesci a sostenere una conversazione puramente tecnica
 senza scatenare l'adulto che c'è in te... beh.
 
Ciao Bruno


 Ciao 
 
M'è particolarmente piaciuta la risposta di @Alex: non è semplice predisporre un'applicazione Access multiutente di tipo "bound" a prova d'inghippi.
Va premesso che nella larga maggioranza delle situazioni le multiuenze sono piccine e poco conflittuali, quindi può andar bene il blocco ottimistico.
Diversamente, si può predisporre un boolean ad-hoc in ogni tabella da gestire programmaticamente: su modifica del Record si controlla lo status del Flag:  se = False si setta = True e si lascia procedere (dopo aggiornamento del Record si deve resettare a False). Al contrario, se lo status apparisse = True non dev'essere consentita la modifica dei controlli a Video.
In fin dei conti è una bella rottura, e non c'è da stupirsi che pochi se la vogliano smazzare. A meno che il settore di riferimento del software in oggetto, contempli abitualmente vaste e conflittuali multiutenze. 
 
Tieni conto che in ogni caso, qualunque strategia si utilizzi, tanti utenti concorrenti potranno sempre incontrare difficoltà. Nel caso di cui si parla, pensa a pincopallino che in fase di modifica record abbandona la postazione di lavoro per la pausa caffè ... gli altri devono aspettarne il rientro per modificare quella riga.
 
Comunque, concludendo non ho ben capito l'architettura del gestionale di cui parli:
 
- Applicazione Desk sviluppata in Access che risiede in Cloud / RDP ?
- Base Dati Server acceduta via ODBC oppure .mdb/AccDB ?
- Quanti utenti?
- Realmente modificate (ordinariamente) contemporaneamente gli stessi record?
 
Saluti
 
 

Con i Progetti ADP se non ricordo male, funzionava molto bene il Blocco Record di tipo Pessimistico, o quello che viene definito "RECORD  MOFIFICATI", nel caso in cui si gestisse la Form BOUND con una SP che mirava al singolo Record...
Questo metodo purtroppo con Access non ha il medesimo risultato, Blocca ugualmente tutto il Recordset anche quelli non in EDITING, ed in effetti sempre rimanendo in tema Bound, come fanno il 99% degli sviluppatori di Access, si accetta il Blocco ottimistico perchè in ogni caso mette al riparo senza particolari rogne, purtroppo viene meno propio la gestione del FEEDBACK, ma raginandoci bene... è assurdo chiederla in modo ANTICIPATO...
 
Per poi scendere nel dettaglio e dare un'ulteriore indicazione teecnica, l'attivazione della fase di EDIT, di conseguenza del BLOCCO avviene solo quando si attiva una modifica, non se si scorrono i record, e quando si scorrono il Blocco non è detto venga resettato... dipende.
Se lo scenario è che 2 UTENTI sono in READ sullo stesso Record, poi uno inizia l'EDIT è assurdo che l'altro possa avere una SEGALAZIONE non essendoci NULLA che va in lettura continua a riconoscere lo stato del Blocco... 
 
@Alex