In sintesi : Cattiva programmazione orientata al cliente con conseguente Bad UX.

Essendo che il programma sfortunatamente è utilizzato (a quanto pare in prevalenza) da persone che non sanno leggere una guida, i programmatori di Incomedia hanno pensato intelligentemente di vincolare il database nella fase di esportazione, e come se non fosse abbastanza, ne hanno vincolato il prefisso delle tabelle rendendo il parametro non editabile.

Nelle migliori delle casistiche, come da te riportato, inserendo dei dati generici riesci a bypassare il problema, mentre se ti va male, sei costretto ad aspettare un intervento da parte dello Staff, in quanto il programma "blinda" la modifica dei campi db.

Dovrebbero pensare di riportare nello Step 5 > Analisi la posizione esatta dell'oggetto o funzione che usa il database, quando lo stesso non è collegato correttamente, a da qualche parte, importare lo sblocco in autonomia dei campi quando ad esempio l'utente ha variato database sul server o hosting.

Grazie Gabriele, a quanto pare la cura è peggio del male, sul forum ci sono decine e decine di problematiche sulla nuova (NON) gestione del DB e non si è ancora pensato (dopo mesi) di trovare una soluzione.

(A parte quella assurda di inviare il progetto allo STAFF)

E' un vero peccato tutto questo.

nell'attesa dello STAFF...

e a meno di un baco...

Se ti chiede il DB hai iun servizio che lo richiede...

- statistiche website

- invio ordini a db

- registrazione automatica

- form su db

- commenti su db

- oggetto dinamico su db

spero di averli elencati tutti

Il problema qui è solo uno, l'ottusità e perseveranza del non ascoltare il cliente. Il povero staff purtoppo oltre a riportare le nostre necessità, altro non può fare. Il problema è che al vertice non ascoltano.

Ovviamente noi abbiamo una visione miope, perché volenti o nolenti non possiamo vedere un insieme delle criticità che hanno portato a tale vincolo, tuttavia una volta imposto, devi consentire a chi ne ha necessità di sbloccare in autonomia il progetto.

Perché qui, non è solo Gabriele o Luca a farlo presente, come quietamente riportato. Senza dimenticare che tale problema era stato segnalato in fase di Preview, prevedendo correttamente il disagio dell'utenza, e tutti i post che si vedono confermano che qualcosa ci abbiamo azzeccato.

Il fatto d'inviare il progetto per tale problematica è una cosa grave e non solo perché mi limiti l'uso del progetto. Dal mio umile punto di vista non è risolutivo per tutti. Io in qualità di cliente per tutta sincerità, in tale aspetto, mi sento "violato" nel dover condividere il progetto quando non strettamente necessario.

Nel mio caso, così come per molti altri utenti, il progetto è pieno dei dati sensibili di tutti i clienti che hanno avuto relazioni con il mio sito. In questa circostanza non possiamo rimuoverli per poi inserirli in un secondo momento.

Inviando il progetto a Incomedia, noi trasmettiamo involontariamente dati sensibili a terze parti, oltre al fatto di comunicare le password di accesso al database e hosting che ci espongo ulteriormente qual'ora le loro infrastrutture abbiano problemi di sicurezza. Reputandomi in materia "ignorante" e stando alle normative vigenti, questa è una violazione seria con sanzioni abbastanza rilevanti a carico nostro.

In aggiunta almeno nel mio personale caso, inviare un progetto integrale, mi esporrebbe doppiamente essendo che commercialmente vendo progetti di WebSite X5 Pro, ergo Tizio può tranquillamente accedere sul server e scaricare quello che gli pare se in cattiva fede, oltre a visualizzare nomi e cognomi ed email dei clienti.

Ovviamente qui non metto in dubbio personalmente Incomedia, perché ho fiducia in loro, tuttavia qui Incomedia deve tutelarmi e lei stessa mettersi nei miei panni, perché io a mia volta rispondo ad altrettanti clienti, in qualità di amministratore del sito.

Ma come dice la mia saggia nonna, non c'è peggior sodo di quello che non vuole ascoltare.