Newsgroup: it.comp.lang.visual-basic
Titolo: Che bella figura da niubbo...

Ve l'avevo piů detto che alla fine , sono riuscito a vendere
un gestionale ? :))
Ehehe, dall'alto dei miei 23 anni, sono riuscito a farmi
pagare 750 euri :)
Il tizio mi paga dietro l'assicurazione che io gli offra
assistenza tecnica per tutto quel che riguarda il mio
programma e i problemi che verranno.
Piu che giusto direi.
Mi chiamano due tre volte dalle varie sedi di roma in cui
hanno installato il programma e io da da bravo galoppino :)
andavo la' , trovavo la cazzata fatta e gli rispiegavo come
funzionava il programma per la duemillesima volta.
Stamattina mi squilla il cellulare: "Sig. XXX? Guardi
abbiamo un problema con la nostra sede a Magliana. Credo che
il Database si sia improvvisamente cancellato del tutto."
Mi viene da sorridere. Gli spiego per la duemillesima e una
volta che il bottone "Resetta Database" andrebbe premuto
solo l'ultimo del mese e che cmq, serve una password per
cancellare il database con quel bottone. L'unico , tra
l'altro, ad avere una funzionalita' del genere.
La password la ha solo il responsabile di quella sede. Ergo
la colpa č vostra. O di qualcuno che si diverte a smanettare
software che non gli compete.
Mi assicurano che nessuno ha tocato niente. "Vedremo" penso
io.
Cmq, per amor del mio lavoro dico loro che sarei andato li
entrop un ora.
Un ora dopo sono la. Vado al pc incriminato e, sicuro di me,
do' un occhiata al software...
Dovete sapere , che ho avuto la buona idea di fare un backup
del database , ogni volta che si preme "reset Database". In
questo modo, nessun dato viene perso.
(Esso'popocheunprogrammatore :)
Effettivamente il Database č vuoto.
Vado nella cartella dei backup e tutti i backup presenti
hanno data precedente a quella di oggi....la data sul pc č
esatta....
MMh...Cazzo....
Non so che pensare...com'e' possibile che il DB  si sia
cancellato ( i dati all'interno intendo ) praticamente senza
premere nessun bottone ?
Cio'e...non vi sto  chiedendo di legere la sfera di
cristallo...
pero' magario..boh..,.che ne so...un vecchio baco in cui
sono caduto...
oppure...che ne so...fatemele voi le domande.. :) rispondo
volentieri :)
Vado a dare un occhiata al codice :))
Spero che mi aiutiate :)
Un bacio ('mmazza che frocio che so' ...)
+[AKUMA]+

 premere nessun bottone ?
Scassato (uno, non tutti) è possibile. Inaccessibile, "inapribile", pure, ma
che si apre ed è vuoto non mi torna. (Cartella TEMP o TMP?, vedi il post
"access non va (e vb dao neanche)")

Che fai una compatazione da qualche parte?
Controlla.
Ciao.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 E se anche fosse (ADO/X escluso)?
Jro.
A volte mi è capitato che la comapattazione non funzionasse e gestendo
male il codice per la sostituzione del database mi trovavo con il db
cancellato.


 cancellato.
Usate DAO. E' semplice, sicuro ed affidabilissimo. Pochi bachi, documentati.
Lo amo!!!

Usate DAO. E' semplice, sicuro ed affidabilissimo. Pochi bachi, documentati.
Su Access sicuramente su SQL qualche difetuccio lo ha

*massi69* ha scritto:

DAO su SQL? L'ho usato (con tabelle Access collegate alle gemelle SQL
Server). Risultato? Prestazioni simili a ADO per SQL Server!
Che c'azzecca la compattazione (ADO???, JRO o DAO) con SQL Server?

Server). Risultato? Prestazioni simili a ADO per SQL Server!
Con la compattazione nulla ovviamente ;) Ma con le transazioni molto !
Lo so che non c'entra nulla con il problema iniziale pero con DAO se
metti una tabella all'interno di una transazione resta lockatta fino a
che la transazione non viene chiusa e questo porta come risultato che
altri utenti che accedono alla tabella restano in attesa fino a che
questa non viene liberata.

 Lo amo!!!
C'e' feeling .... ^_-

*massi69* ha scritto:


Per predisporre la massima (non totale!) sicurezza, mi sembra piů che
logico.
Seriamente.
Alternativa? Non usare le transazioni.
PS: Notata una certa ricorrenza di post sulle transazioni, su vari tipi di
db?
IMHO: Quel che č troppo "figo", prima o poi non funziona.
Perchč? Non perchč č troppo figo, ma solo perchč _non puň funzionare_.
Non sto scherzando. Nella mia avanzata sclerosi, la penso esattamente cosě.

Non sto scherzando. Nella mia avanzata sclerosi, la penso esattamente così.
Be che all'umentare della figosità aumentino i problemi è vero !

 Be che all'umentare della figosità aumentino i problemi è vero !
Appunto. Vedrò di continuare a vivere tranquillo, per anni... ;-)
Lupo.Comandamento:MaiUsareCiòCheNonE'Indispensabile.MAI!!!


Si pero sull'uso delle transazioni si potrebbe aprire un dibattito ;-)

 Si pero sull'uso delle transazioni si potrebbe aprire un dibattito ;-)
Certo, ma io ho già detto (tutto) quel che ne penso.

 Server). Risultato? Prestazioni simili a ADO per SQL Server!
Da DAO A ADO con tabelle Access collegate a Tabelle Sql Server
Da 3 ore a 1 ora in tempo di calcolo su 36.000 record (Sommatorie di
Bilanci)
Ciao
Alessandro
--
Morfeus®
Free Joint
:PII

Da 3 ore a 1 ora in tempo di calcolo su 36.000 record (Sommatorie di
Senza parlare poi di feature carine come le query asincrone, o la
gestione delle stored procedure....

 Bilanci)
Ci può stare (con quelle dimensioni)
Io, comunque, ho parlato di DAO con tabelle collegate a SQL Server, non di
ADO.
Tu intendi la stessa cosa anche per ADO? Spero di no.
Ovvero spero che non ci sia un Access di mezzo fra ADO e SQL Server.
In ogni caso, DAO (verso Access) è stratosfericamente più veloce di ADO.
ADO (verso Access e verso SQL Server) è pietosamente lento e, per quanto mi
riguarda, da cestinare con gli autori.

*massi69* ha scritto:

Lasciamo stare... già dato.

 per quanto mi riguarda, da cestinare con gli autori.
qui dovresti mettere un bel IMHO
Ma cosa valgono questi discorsi in ADO.Net?
#Region "Ot Interno"
 A questo proposito vorrei sollevare un pensiero non dovremmo incominciare a
dismettere Win98?
#End Region


dismettere Win98?
Io già dismesso tutta la famiglia Win9x+ME

 #End Region
Ok, sei un troll o, in subordine, un M$. Corri che ti scappa.

 ha scritto nel messaggio
news:tjh4cvo3tf257v80o...@4ax.com

Non personalmente quello è scontato.Ma per i clienti, alla fine dovremmo
essere noi a dettare lo standard e dal momento che VS7 su win98 nemmeno
riesco a immaginarlo( a proposito ma ci gira?) e come questo anche , e Lupo
non se la prenda a male , Access almeno fino a quando non cambia qualcosina.


non se la prenda a male , Access almeno fino a quando non cambia qualcosina.
Io su "accesso" ho le mie opinioni ma preferisco non divulgarle ;-)

 Ok, sei un troll o, in subordine, un M$. Corri che ti scappa.
è una cosa Bella?Grazie


 del database , ogni volta che si preme "reset Database".
Fine del mese gennaio
Resetto avrň un Backup completo, chiamiamolo gen
e il programma di produzione Gest vuoto.
Se per uno scrupolo, non ricordo se ho eseguito l'operazione di Reset,
rieseguo,
per caso il backup precedente viene riscritto ?
Il questo caso mi trovo gen vuoto.
E' un'ipotesi.
giuseppeD

 è una cosa Bella?Grazie
No, bruttissima, in entrambi i casi.

 premere nessun bottone ?
Ma... io ho avuto un problema simile con un prog. che usava access97 via
ODBC.
Successo una volta sola, ma sono rimasto allibito: 2 DB diversi acceduti
tramite ODBC, tutto va da settimane ormai, a un certo punto la telefonata
che mi annuncia la catastrofe: non va piů niente.
Dopo un quarto d'ora di controlli ho soperto che uno dei due DB, pur
conservandone il nome aveva la struttura (tabelle) dell'altro.
Ovviamente il mio prog non faceva nessuna copia/confronto tra i due.
Ma tu sei sicuro che nessuno ti sia entrato da access e non ti abbia
cancellato tutto?
Ciao

 Caruccio!
cut
Scusa Lupo eh!
io non vorrei rifare il discorso di un po di tempo fa......e non voglio
carpire i segreti di nessuno....
Premessa: per gestionale....cosa si intende?....tutto e nulla....
Gestionale per gestire una autofficina?....
Gestionale Contabilità?
Gestionale di Magazzino?
Gestionale per agenzia di viaggi?
ok non sappiamo cosa ha fatto akuma.....
Ora la mia domanda...io non vorrei strapparti segreti...ma secondo te quanto
vale un gestionale?
come fai a dir caruccio...quando io avrei detto....mmm anche troppo basso
(750 ...levaci l'iva...quanto rimane?)
...a meno che non sia poco più di un planner....
E per la rete?
io ci applico il 30 40% (dipende dal cliente) sul prezzo del
Mono....dimodochè non siano spaventati a comprarlo per più di una
postazione...
Solo per sapere !
Arf  e miao!

 No, tanto non ti leggo e in ogni caso, potresti sono confermare.
A parte che dovrei dimostrare il contrario di cosa?
Visto che c'è sempre da imparare ;) fammi capire queste prove che hai tu
sono schiaccianti?Faccele vedè faccele toccà


 cancellato tutto?
hai messo la password anti utonto al db access vero? :?

[Wodka4U(win2k)] scrisse:
(snip)
Mi associo alle considerazioni di wodka
750 euri (per il solo programma) possono essere tanti e pochi. L'unico
gestionale che ho fatto io l'ho venduto a una cifra superiore, ma è stato
fatto su "misura" per il cliente, e sono cose che imho si devono far pagare.
Su quanto ci si faccia pagare in genere, poi, bisognerebbe aprire un bel
dibattito: sento parecchia gente, da queste parti, che si lamenta del fatto
che ci siano solo 24h in un giorno,e allora mi sorge un dubbio
1) stiamo cercando (mi ci metto anch'io, và) di fare il primo milione perchè
siamo smodatamente avidi
2) non siamo capaci di lavorare e/o abbiamo strumenti che ci creano più
casini di quanti ne risolvano
3) ci facciamo pagare troppo poco, e se non lavoriamo 25 ore al giorno per
otto giorni alla settimana non riusciamo a sbarcare il lunario.
4) altra ipotesi (da specificare)
tu / voi cosa scegli / scegliete?
Salutoni
Sergio

 sono schiaccianti?Faccele vedè faccele toccà
Imbecille.

 postazione...
Infatti, per la rete (e anche per le ... varie filiali) ci sono delle
maggiorazioni che non mi pareva AKUMA avesse previsto, pur gestendole, o,
almeno, non ne parlava.

 ha scritto nel messaggio
news:b9tlsj$mq9o9$
1...@ID-174464.news.dfncis.de

mi rincresce vedere quanto ti stai incazzando ,ma non mi sembra che avevo
usato termini pesanti come stai facendo tu,nemmeno termini che potessero
farti scaldare,escluso puffo,  e mi rincresce constatare quanto internet
influisca negativamente sulla comunicazione tra persone,introducendo un
dialogo a distanza ,avrei gradito vederti mentre mi chiami imbecille,ROTFL e
forse lo sono ROTFL ma non pensiamo a questo piuttosto ti ho portato un
regalino
http://www.visual-basic.it/uploads/articoli/tecnici/afDaoAdo.htm


 Sergio


http://www.visual-basic.it/uploads/articoli/tecnici/afDaoAdo
.htm
"A coloro che desiderano interfacciarsi ai database MDB
(Access per intenderci) non sconsiglio l'utilizzo di ADO (ci
mancherebbe), ma ricordo che il database di Microsoft non è
propriamente indicato per lo sviluppo di applicazioni
multiutente, non essendo un database Client/Server, e che
quindi il buon Provider OLEDB deve simulare quello che
invece DAO esegue in modo nativo, cosa che va a discapito
delle prestazioni."
Lokar
--
Sito Comune: 
http://www.it-lang-vb.net/
Manifesto: 
http://www.it-lang-vb.net/docs/Manifesto.txt
UGIdotNET - 
http://www.ugidotnet.org

 Lokar
I coloro non sono io .La prossima volta inizia a leggera dall'alto e poi
quello che dici tu non mi risulta :
DAO supporta in modo nativo il DBEngine(Access,Ok) che in ADO non c'è più
( utilizza OLE-DB data provider accesso diretto alla fonte/i dati SENZA
UTILIZZO DI INTERFACCE  vedi per esempio DBEngine),non vedo dove quello che
dici tu è giusto.
DAO casomai è consigliabile per facilità d'uso e velocità "d'impego" per
applicazioni di Piccolo Taglio e orientate verso DB Access era questo il
nocciolo della questione(arileggi più sù,ehhmm non troppo più sù ;) lì si
parlava d'altro siamo molto Ot)
Vorrei che *almeno tu* lo considerassi Solo uno scambio di opinioni , e io
rimango della mia.Anch'io ho utilizzato DAO per moltissimo tempo ma è morto.


 dove quello che dici tu è giusto.
Senza alcuna polemica, considera questo fatto: come mai per far girare un
programma che si appoggia su un mdb tramite ADO, oltre a MDAC devi
installare JET ?
Salutoni
Sergio

 Anch'io ho utilizzato DAO per moltissimo tempo ma è morto.
Come te, per quanto mi riguarda! R.I.P.!
PLONK!


 
http://www.visual-basic.it/uploads/articoli/tecnici/afDaoAdo.htm
Fatti, non pughette (fra parentesi, sarei felice se ADO andasse veloce, così
non è):
http://www.it-lang-vb.net/download.asp?file=Archivio/Sorgenti/VBDAOADO.ZIP&I
D=577


Molto incuriosito ho scaricato il lavoro che hai fatto e l'ho un po
guardato, una sola osservazione perche non hai implementato gli
esempio con Command dell' ADO per SQL-Server?

*massi69* ha scritto:

Perchč allora mi serviva una prova ... veloce
e anche un po' perchč...  non uso il Command... ;-)
(Non insisto, potrei sbagliarmi clamorosamente, ma mi par di ricordare che
crei anche qualche problemino, leggendo in questo NG)

 giorno 4) altra ipotesi (da specificare)
4 io sono uno e i clienti tantini di più...
tutti vogliono qcosa e quindi per finire prima il mio lavoro (e dormire fino
alle 10 anche il sabato ^_^)
dovrei lavorare di +...ma per lavorare di + dovrei avere + ore...tutto lì.
Penso di gestirmi bene il tempo (oggi sono le 18.41 e mi appresto ad andare
a casa) e di farmi pagare...
ma in certi periodi non ci si sta dietro..
Alex
PS: 750 eurO vanno bene se il lavoro è di 2-3 giorno...se no...


==============
Difficile determinare il prezzo di qualsiasi gestionale.
Difficile determinare quanto tempo è lavoro, e quanto tempo è studio...
perchè ci sarà sempre una parte anche piccola che per noi è assolutamente
nuova.
Una persona abbastanza brava che io conosco, e con tanti clienti, mi diceva
una volta che lui fa pagare, per un gestionale semplice "su misura",
scegliendo il criterio delle tabelle del database: 250 euro per ogni
tabella.
Greg

 tabella.
Un costo a tabella???
Fatto in Access (l'applicativo intendo)?
Perdonami, ma deve essere mooolto semplice...


Database in Access e programma in VB... e deve essere semplice, certo.
Grge

 Alessandro
==================
Sono tempi assolutamente impensabili con DAO-Access
Ma credo che si dobrebbero considerare come inaccettabili con qualsisi
tecnologia.
Greg

*Tyss* ha scritto:

Ok, ma, sinceramente, non capisco come si possa fare un prezzo di un
gestionale in base al numero delle tabelle e non sulla complessità (o
semplicità) del pacchetto, nella sua interezza.
Per esempio: Per quanto mi riguarda, ogni tipo di documento gestito
(preventivi, ordini, bolle, fatture, etc.) sta sulle stesse due tabelle
(testata e dettaglio), ma se devo gestire le commesse di lavorazione (pur
non aumentando il numero delle tabelle) ci carico sopra una bella cifra.
I consulenti (almeno una volta) facevano il prezzo sul numero di righe
registrate sul libro giornale, quello era effettivamente l'impegno nella
quotidianità. Poi, magari, aggiungevano qualcosa per la chiusura del
bilancio, registri vari, etc.

 Morfeus®
=============
Vai sul sito comune e scarica il programmino di Lupo che testa la velocita
di dao-ado-access-sql. Lancialo e poi leggi i risultati...
Greg

*Tyss* ha scritto:

Gli ho postato il link diretto. Restiamo in attesa.


Sul fatto ADO-DAO-ACCESS trovo il test interessante e cmq è roba che
già si sapeva ma su SQL SERVER non sono state usate alcune
ottimizzazioni obbligatorie per migliorare le prestazioni e sopratutto
non puoi ragionare in SQL come ragioni in ACCESS.

*massi69* ha scritto:

Mi dici, per favore, quali ottimizzazioni? Mi interessa molto, seriamente!
Grazie.


Be il fatto stesso con non usa Command per ADO che ti permette di
lanciare query specificando se devono ritornare recordset o essere
query di elaborazione in termini, tramite il comando adCMdText, la
possibilità di utilizzare di utilizzare RecordSet disconnessi, il
fatto stesso che la logica del DB la tieni nel programma va pendere
sicuramente il lato del tuo test verso DAO ma per il fatto che hai
preso la logica ACCESS e l'hai portata su SQL Server e sicuramente in
questo modo non ottieni nessun miglioramento.
Se il tuo test è prendo il programma lo porto su SQL Server e non lo
modifico allora il test è corretto, anche se sbagliato, se il test è
vediamo se su SQL SERVER è piu veloce DAO o ADO il test non server a
nulla.

 nulla.
Ho la sensazione che wodka salterà addosso a questa frase. Puoi tradurre?

 nulla, è meglio che lo tieni in ACCESS.
Ok, è più chiaro, ma non capisco sinceramente come una transazione possa
migliorare le prestazioni, mi parrebbe logico il contrario.
Non capisco nemmeno come una SP (precompilata) possa essere più veloce di un
comando SQL diretto (da compilare) quando il quadagno è sulla pura fase di
compilazione (diciamo 1, persino 10 secondi?) e la costruzione del recordset
dura 10 minuti... Cioè, fammi capire, impiego 10 minuti - 10 secondi? E'
questa la maggior velocità?

 cancellato.
Sì.
L'operazione di compattazione con Jro è strana, e in un certo senso
cricitca.
Siccome di fatto il db viene compattato su un nuovo nome (diciamo che db1
diventa db2), successivamente occorre backuppare db1, cancellarlo, e
rinominare db2 in db1.
Problema: e se il backup di db1 non va (disco pieno, diritti di accesso su
NT, ecc...)?
Allora devo eliminare db2 e continuare con db1.
Problema: e se la compattazione non va (ad esempio disco pieno), ma questo
avviene dopo che db2 è già stato creato e non ancora popolato?
Allora devo eliminare db2 e proseguire con db1.
Problema (classico che si vede dopo ad esempio un mese): dopo aver
compattato db1 in db2, e sovrascritto db1 con db2, dimentico di eliminare
db2. Alla compattazione successiva, questa non va. Però, se non gestisco la
cosa, vado a sovrascrivere db1 con un db2 vecchio di un mese.
Se non gestisco queste cose, potrei eliminare db1 senza averne un backup, e
sostituirlo con db2, che a sua volta potrebbe essere difettoso.
Non entro nel merito della scelta di Access anzichè roba tipo MSDE. Mi rendo
conto che per applicazioni semplici la comodità di distribuire un mdb senza
installare nient'altro che l'app, è notevole.
Tuttavia, i rischi esistono.
Nella compattazione in particolare.
Non so come funzioni con Dao.
Però, se anche con Dao si crea un nuovo mdb, il problema di gestire questa
situazione di due file vecchio e nuovo, credo esista comunque.
Ciao
Alberto

comando SQL diretto (da compilare) quando il quadagno è sulla pura fase di
LA sp viene eseguita dal Server, come anche view che in SQL Server
2000 possono essere anche indicizzate, in maniera diretta dal Server e
su grandi moli di dati la differenza la senti, come esperienza
personale portando la logica di un programma di magazzino scritto in
DAO, in ADO con sp e view sono sceso da tempi conferma di un movimento
di minuti in secondi, mentre il cambio da DAO in ADO mantenendo la
stessa logica non aveva portato a nessun miglioramento.
Tieni inoltre conto che quando fai una stored procedure usi il
linguaggio T-SQL che ti permette di fare piu cose rispetto all'uso che
puoi fare di una query+logica programma sul client

 E' un'ipotesi.
Questo post, che leggo solo adesso, è stato ignorato da tutti.
Ma credo sia molto centrato sul problema...
Ciao
Alberto

 Ma credo sia molto centrato sul problema...
Io non l'ho ignorato, anzi ho pensato subito che fosse qui
la magagna (anche se dal post di AKUMA *non* si evince se i
backup erano vuoti o meno).
AKUMA ha lanciato la pietra... e ritirato la mano. Nel
thread non si e' piu' fatto sentire.
Aspettiamo...


 la magagna
... idem.

 tu sono schiaccianti?Faccele vedè faccele toccà
difatti ho visto il prg del sito comune e non mi pare che ci sia nulla da
imparare, ho forse detto ADO più veloce di ADO su ACCESS?,casomai l'IMHO era
perchè *tu* affermi che ADO è meno veloce di DAO (difatti parli di simili
prestazioni, ma da quello che vedo ADO lo usi male**) su base dati diverse
da access  o no?
**
Nel tuo progetto
 rs.Open txt_sql.Text, db, tipo_cursore, tipo_blocco
txt_sql.text->SqlString
db->Origine
tipo_cursore->TipoCursore
tipo_blocco->TipoBlocco
Opzioni->Dov'è?No di certo nella tua testa IMBECILLE
#Direttamente da MSDN
Sintassi
recordset.Open Origine, ConnessioneAttiva, TipoCursore, TipoBlocco, Opzioni
Se non si passa un oggetto Command nell'argomento Origine, sarà possibile
utilizzare l'argomento Opzioni per ottimizzare la valutazione dell'argomento
Origine. Se l'argomento Opzioni non è definito, le prestazioni potranno
risultare ridotte dal momento che è necessario effettuare chiamate al
provider per determinare se l'argomento è un'istruzione SQL, una stored
procedure o un nome di tabella.
#Fine MSDN
Per quanto riguarda [Lokar] :
Posta un messaggio a mio avviso inutile dicendo e citando cose per altro che
ho fatto già io e che nel contesto del discorso non c'entra un cazzo, da
quello che lui dice(ma lui non aggiunge nulla o almeno il "senso" del suo
post visto che ha risposto a Me) io dovrei rimettere DAO nel mio progetto?
Per chi volesse vedere Osservatorio 2000 può recarsi presso la ConfCooper
e/o presso il Ministero dell'agricoltura a Roma e nel caso decidiate di
venire fatemi sapere ;) così parliamo pure dell'emerito imbecille più volte
citato.
e qui riporto la mia risposta a Lokar
"DAO casomai è consigliabile per facilità d'uso e velocità "d'impego" per
applicazioni di Piccolo Taglio e orientate verso DB Access(non il mio caso)
era questo il
nocciolo della questione(arileggi più sù,ehhmm non troppo più sù  lì si
parlava d'altro siamo molto Ot)"
Alessandro


Akuma o per un modo o per un altro scatena sempre 3ad kilometrici ^_^
cmq potrei esprimere una considerazione su sta schifezza di 3ad ?
MA CAMBIARE IL SUBJECT NO EH ? ^_^

 citato.
Sei pure borioso.