text:
Allora, intanto come ti ho indicato la ListBox mette a disposizione la Collection
ItemsSelected che già contiene SOLO i selezionati, quindi non ti serve discriminare se lo sono, quindi il codice che hai scritto è meglio scriverlo come sotto...!

Seconda cosa che non spieghi, ma sarebbe meglio, è il motivo per cui devi ripristinare la selezione...

Ad ogni modo, ti ho scritto 4 righe di codice che, dopo la selezione della listBox se premi salva SALVA gli Items Selezionati, e compone la Stringa per il Filtro con IN(Valore1,Valore2...)
Azzera i selezionati e se premi Ripristina li riseleziona.

Option Compare Database
Option Explicit

Private sSelected   As String

Private Sub cmdSalva_Click()

    Dim varItm     As Variant

    For Each varItm In Me.Elenco0.ItemsSelected
        sSelected = sSelected & Me.Elenco0.ItemData(varItm) & ","
    Next varItm
    If Len(sSelected) > 0 Then
        ' Tolgo l'ultimo separatore per avere la stringa corretta per il filtro
        sSelected = Mid$(sSelected, 1, Len(sSelected) - 1)
        MsgBox "NOT IN (" & sSelected & ")"
    End If
    ' Questa serve solo per RIPULIRE la selezione in modo veloce
    Me.Elenco0.RowSource = Me.Elenco0.RowSource
End Sub

Private Sub cmdRipristina_Click()
    Dim i           As Integer
    Dim sT          As String

    ' Aggiungo il separatore per non trovare i Numeri compositi...
    ' ES se hai un ID=1 ed un ID=10 rischieresti di selezionarli entrambi
    ' inserendo il Separatore invece no.
    sT = sSelected & ","
    For i = 0 To Me.Elenco0.ListCount - 1
        If InStr(sT, Me.Elenco0.ItemData(i) & ",") > 0 Then
            Me.Elenco0.Selected(i) = True
        End If
    Next
End Sub

Saluti

@Alex


title: mantenere elementi selezionati in casella di riepilogo

author: mario rossi

text:

Il motivo è che in alto ho messo 3 pulsanti che se cliccati cambiano l'ordinamento degli elementi visualizzati nella casella di riepilogo per comodità di ricerca degli elementi, inoltre ho aggiunto a fianco dei 3 pulsanti una textbox che inserendo una stringa applica un filtro agli elementi della casella di riepilogo e un pulsantino alla destra della textbox che se cliccato rimuove il filtro rivisualizzandoli nuovamente tutti e ordinati in base al pulsante dei 3 che era stato cliccato.

oggi provo le tue indicazioni grazie.


text:
Il giorno martedì 12 maggio 2020 10:56:36 UTC+2, @Alex ha scritto:

mi chiedevo una cosa, se le categorie sono 1500 questo codice diventa impegnativo dovendo scorrere ogni volta tutte le categorie dell'elenco per riselezionare le selezionate precedentemente?


text:
Sono tanti 1500 anche solo per lo scorrimento...
Non puoi gestirli con qualche raggruppamento in gerarchia...?

@Alex


text:

no sono tutte categorie distinte, forse allora potre usare una sottomaschera con il controllo opzione Si/No che se cliccato poi lo considero selezionato in questo modo non devo ogni volta salvare e poi recuperare i selezionati come devo invece fare con il controllo elenco casella di riepilogo?


text:
Non ho capito... ma io intendevo una cosa simile:

Categoria1
  SottoCat1
  Sottocat2
  SpttoCat3
  ...
Categoria2
  SottoCat1
  Sottocartelle
  ...
Ecc...

In questo modo si può restringere la selezione con una selezione Principale e poi una secondaria...riducendo molto le combinazioni.

Per il resto non ho proprio capito come hai strutturato la cosa quindi non so cosa dire.

@Alex


text:

mi spiego meglio attualmente avevo optato per caselle di riepilogo ma dovendo applicare filtro o cambiare ordinamento degli elementi e essendo molti gli elementi della casella di riepilogo (circa 1500)

per evitare di (punta A)
salvare gli elementi selezionati
applicare il filtro o riordinare gli elementi con criterio diverso
poi recuperare i selezionati

potrei:
usare una sottomaschera che funziona in modo simile alla casella di riepilogo con 2 campi

a sinistra capo "sel" di tipo si/no con opzione caselle di controllo
a destra la categoria
cosi chi vuole selezionare la categoria clicca la casella di controllo imposto a -1 quel campo e quindi evito quanto indicato sopra al punto A


text:

ho fatto cosi alla fine, molto più rapido e evito di dover salvare e poi recuperare gli elementi selezionati ogni volta che applico un filtro o cambio ordinamento

in pratica ho aggiunto un campo "selezionato" di tipo "si/no" ed ho sostituito la casella di riepilogo con una sottomaschera con a sinistra l'opzione "selezionato" e a destra la descrizione categoria

poi uscendo dalla form principale eseguo query di aggiornamento che pone a false il campo "selezionato" di tutti i prodotti il suo campo "selezionato" è true


title: Il file del gruppodi lavoro

author: kleiber Visconti

text:
Ho realizzato un'applicazione in Access 2000 ed uso Windows 2000.
Ho creato un gruppo di lavoro per la protezione con relativi Utenti e
Gruppi, ho chiamato questo file "PROTEZIONE.MDW" e ho posizionato questo
file nella directory dell'applicazione.
Dopodichč ho utilizzato il programma WRKGADM.EXE per rendere attivo questo
file e tutto funziona perfettamente.
Il problema č che con questo sistema il file cosě creato č attivo anche per
altre applicazioni che invece hanno il loro file .MDW di protezione diverso.
Come posso fare per far sě che ogni applicazione veda in automatico il suo
file di protezione?
Grazie


title: Il file del gruppodi lavoro

text:
"Landers" <
lan...@spidernet.it
> ha scritto nel messaggio
> Ciao kleiber,
> ho lo stesso problema anch'io. Spero che qualcuno ci risponda.......
Mi sà che forse è un problema troppo difficile.......


title: Il file del gruppodi lavoro

author: VT @ home

text:
Il Sat, 31 May 2003 19:14:15 +0200, "kleiber Visconti"
<
kle...@email.it
> ha scritto:
>(.....)
>Come posso fare per far sě che ogni applicazione veda in automatico il suo
>file di protezione?
>Grazie
>
Crea un collegamento per ciascuna applicazione, in cui nella casella
"Destinazione" scrivi il seguente comando:
Percorso\msaccess.exe tuodatabase.mde /wrkgrp percorso\protezione.mdw
Per maggiori info, guarda l'help alla voce
Opzioni della riga di comando per l'avvio
Vincenzo Turturro
---------------------------------------------
il sito comune di it.comp.appl.access:
http://www.sitocomune.com/
---------------------------------------------
E quello di it.comp.as400
http://www.faq400.com/
---------------------------------------------


title: Il file del gruppodi lavoro

author: Landers

text:
Io ho risolto cosě:
Vai sul sito comune
www.sitocomune.com
Sezione: "General"
Argomento: "Come utilizzare la sicurezza di Access?"
Qui trovi un'ottima spiegazione gentilmente "offerta" da Cristiano De
Pasquale
Ciao.
--
Posted via Mailgate.ORG Server -
http://www.Mailgate.ORG


title: Il file del gruppodi lavoro

author: Enrico T.S.

text:
"kleiber Visconti" <
kle...@email.it
> ha scritto nel messaggio
news:dRoCa.4641$Fr5....@tornado.fastwebnet.it...

Non e' difficile, dovete semplicemente
associare il file MDW all'applicazione
passandolo come argomento alla linea di comando
se non ricordo male una cosa del genere :
"C:\Programmi\Microsoft Office\Office\MSACCESS.EXE" "c:\programmi\tuodb.MDB"
/wrkgrp "c:\protezione.MDW"
bye :o)


title: Access versus Visual Basic. Chiedo aiuto per prendere una decisione importante.

author: Ludus

text:
Chiedo aiuto agli esperti. Ho provato a cercare nel Sito Comune ma non
ho trovato un approfondimento sull'argomento.
Si tratta di questo: una grande azienda di Torino possiede un
centinaio di negozi (grandi magazzini) dislocati in tutt'Italia. Ogni
negozio ha due o tre registratori di cassa.
Questi registratori sono composti da una apparecchiatura IBM (che è
praticamente un Personal Computer), corredato da un monitor a colori
14 " di tipo  touch screen,  tastiera, mouse, dispositivo per la
lettura del barcode, fessura di scorrimento incorporata nella tastiera
per la lettura di badge, più un piccolo display rivolto verso il
cliente, affinchè questi possa leggervi il prezzo dei vari articoli,
collegato tramite porta seriale, più una stampantina per l'ottenimento
dello scontrino fiscale,  anch'essa collegata ad altra porta seriale.
Sistema operativo Windows XP per le casse nuove, Windows meno recenti
per le vecchie casse che verranno man mano sostituite.
Le due o tre casse del negozio, sotto l'aspetto dell'operatività, sono
indipendenti. Ogni cassa possiede il software e i dati necessari per
lavorare in modo autonomo.
Il software è costituito essenzialmente da un programma di gestione
della vendita, più vari altri programmi che consentono le
comunicazioni tra il negozio e la Sede, e altri programmi di utilità.
- I programmi sono stati realizzati, a suo tempo, in Clipper / DBase
III dal personale stesso del Centro Elaborazione Dati dell'Azienda.
Il programma di GESTIONE DELLA VENDITA presenta sul monitor, rivolto
verso il cassiere,  le transazioni di vendita man mano che il lettore
laser legge i bar-code sulla confezione dei prodotti, ne mostra il
prezzo tramite accesso ad un data base caricato sulla cassa stessa da
cui trae anche sconti e condizioni di vendita speciali, ecc.  -
Consente la gestione di eventuali resi e di particolari movimenti ed
eccezioni. - Pilota anche per ogni transazione il piccolo display lato
cliente mostrandone il prezzo e a fine vendita stampa lo scontrino
fiscale, oltre a registrare nel data-base le transazioni di vendita
effettuate.
La gestione del display lato cliente e della stampatina fiscale
avviene inviando gli opportuni comandi alle due porte seriali. Ecco
perchè in un mio precedente post (Gestione porte seriali tramite VBA)
chiedevo se ciò fosse possibile in Access. Mi ha risposto cortesemente
Lorenzo.
I programmi di COMUNICAZIONE CON LA SEDE, che ha come computer
gestionale un AS/400, ricevono nottetempo le modifiche ai data-base
degli articoli e dei relativi prezzi e sconti, e trasmettono alla sede
le vendite del giorno precedente.
Vari altri programmi di UTILITA' consentono diverse funzioni
complementari.
Come detto sopra tutti i programmi sono stati realizzati a suo tempo
in Clipper/DBase III e DOS e funzionano egregiamente, anche se con
interfacce piuttosto spartane.
Si è deciso di riscriverli per varie ragioni: per fornire una
interfaccia più elegante (e più efficiente), potendo sfruttare anche
il touch-screen del monitor, utilizzando un linguaggio più moderno e
più conosciuto nell'ambiente informatico, per eventuali future
manutenzioni da parte di terzi, ma anche perchè si temeva (e si teme)
che con nuovi registratori di cassa e con nuovi sistemi operativi il
Clipper, il DBase III e il Dos possano non essere più supportati
compiutamente in futuro.
In qualità di consulente di questa azienda, per rendermi conto della
complessità dell'ambiente, e poichè conosco discretamente bene Access
(e non conosco Visual Basic, né Delphi, né altri linguaggi) ho
iniziato a convertire l'applicazione in Access, partendo dal programma
di Gestione della Vendita che è il più complesso. In effetti non è un
programma banale, ma in Access non presenta particolari difficoltà.
Ma, mentre procedevo nella sua realizzazione, ho cominciato ad avere
dei dubbi, corroborati anche dal parere di alcuni colleghi.
1. LICENZE - Un programma .mdb richiede che su tutte le casse (circa
250)  debba  essere installato Office/Access. Ciò comporta anzitutto
un problema di costo delle licenze. Se una licenza costa circa 220
euro, per 250 casse si ottiene un totale di 55.000 euro. Soldi che
realizzando il programma tramite un altro tool in grado di ottenere un
.exe sarebbero risparmiati.
2. STABILITA' -  Ho la sensazione che un programma Access, anche
perchè dipende da una sovrastruttura Office, sia meno stabile e meno
affidabile, specie quando, con il passar del tempo, le 250 casse
cominceranno a differenziarsi come versione sia di Office che di
sistema operativo Windows, cosa che sicuramente si verificherà a causa
di rotture e guasti sia dell'hardware che del software, che
richiederanno il ripristino del sistema operativo Windows e di Office
nella versione più aggiornata.  Un .exe mi sembra non debba risentire
di questo.
3. COMPILAZIONE - Un programma .mdb è un programma interpretato in
fase di esecuzione. Anche questo fatto mi pare negativo rispetto ad un
programma compilato. - Inoltre un .exe è sicuramente inaccessibile
come codice all'utente. Un .mdb, anche se trasformato in .mde, mi dà
la sensazione che qualcuno delle 250 persone che dovranno usarlo,
possa in qualche modo manometterlo o guastarlo.
4. AMPIEZZA - Un programma compilato è più piccolo. Nel mio caso il
programma Access di Gestione della Vendita, una volta finito, mi
aspetto che sarà grande almeno da 5 a 7 MB. Quindi trasmettere le
nuove versioni a tutti i negozi richiederà più tempo (e minor
sicurezza di trasmissione sulle linee telefoniche), anche se una
versione .mde potrebbe essere più piccola, credo un 10-20% in meno.
5. DATA-BASE. - Questo non mi pare un problema, anche in una soluzione
Access. Infatti mi sono premurato, prima ancora di realizzare la parte
grafica e propriamente elaborativa del programma, di provare i tempi
di risposta nell'accesso al data-base. Questi devono essere molto
veloci, dato che la lettura del barcode dei prodotti avviene
consecutivamente, un prodotto dopo l'altro, a notevole velocità, e per
ogni lettura occorre accedere agli archivi dei prodotti e mandare a
monitor la risposta con prezzo e condizioni. Uno di questi archivi è
molto grande (circa 2.500.000 record). Ma ho constatato che, purchè
siano impostate correttamente le chiavi di ricerca dei record, i tempi
di risposta  sono del tutto soddisfacenti.
5.a - Scegliendo un altro tool di sviluppo al posto di Access si pone
anche  il problema di scegliere il data-base.  Però non vorrei cadere
dalla padella nella brace. Scegliendo un data-base tipo SQLServer mi
pare che avrei di nuovo problemi sia di licenza (per 250 casse circa)
che di complessità. Il data-base .mdb è molto più semplice da
installare e da trattare, rispetto ad un SQLServer, secondo me.
5.b - Scegliendo invece di conservare, come data-base, un .mdb,
risponde al vero che in questo caso, senza programma elaborativo
Access, non è richiesta la licenza? Mi dicono che un eventuale
programma, p. es. in Visual Basic, accederebbe all'.mdb tramite MDAC
(Microsoft Data Access Components - ODBC), e ciò non comporta licenza
Access.
Aggiungo che l'idea di voler convertire l'attuale pacchetto tramite
Access (e non tramite un altro tool di sviluppo) deriva anche dal
fatto che il Centro Elaborazione Dati dell'azienda attualmente è
autonomo nella manutenzione dell'attuale programma Clipper e vuole
continuare ad esserlo in futuro. I componenti del CED possiedono una
buona conoscenza di Access (oltre che di Clipper) ma non di altri
tools di sviluppo.
Tuttavia, se lo sviluppo in Access si dimostrasse una soluzione non
valida, secondo me insistere su questa possibilità potrebbe essere
pericoloso per i problemi che ne deriverebbero in futuro.
Se le Vostre considearzioni saranno negative nei confronti di Access,
suggerirò loro di utilizzare i 55.000 euro risparmiati dalla rinuncia
alle licenze Access per farsi aiutare a convertire l'attuale programma
tramite il tool scelto, e contemporaneamente di acquisire autonomia
nell'uso del medesimo sia con corsi che con manuali.
Mi scuso per la prolissità e Vi ringrazio.


author: MA

text:
Ludus wrote:
> Chiedo aiuto agli esperti. Ho provato a cercare nel Sito Comune ma non
> ho trovato un approfondimento sull'argomento.
Ciao Ludus,
la tua analisi è esaustiva ma parte da conoscenze del prodotto Access e
della sua gestione delle licenze errato. Ti consiglio di leggere l'articolo
dedicato
su
www.accessgroup.it
Access può essere la tua soluzione, tranquillamente, con dei però.
Primo: Access deve essere solo il front end, devi usare SQL Server come
Backend.
A questo punto non preoccuparti, il tutto ti può costare meno di 500 euro
(con un però)
ma rispondiamo punto per punto
[Cut]
> I programmi di COMUNICAZIONE CON LA SEDE, che ha come computer
> gestionale un AS/400, ricevono nottetempo le modifiche ai data-base
> degli articoli e dei relativi prezzi e sconti, e trasmettono alla sede
> le vendite del giorno precedente.
>
[CUT]
Qui devi scegliere se usare AS400 collegato come Backend per tutti o usare
un db SQL, uno solo, anche nella versione Express (cioè free) che curi il
collegamento tra i client e AS400. Io ti suggerisco quest'ultima soluzione
anche perchè così esponi ad internet un db di passaggio e non il db server
(è il principio delle carte di credito prepagate, se interettano quelle il
danno è limitatissimo)
>
> 1. LICENZE - Un programma .mdb richiede che su tutte le casse (circa
> 250)  debba  essere installato Office/Access. Ciò comporta anzitutto
> un problema di costo delle licenze. Se una licenza costa circa 220
> euro, per 250 casse si ottiene un totale di 55.000 euro. Soldi che
> realizzando il programma tramite un altro tool in grado di ottenere un
> .exe sarebbero risparmiati.
Esiste un tool che si chiama Developer kit fino ad Access xp e Visual Studio
Tools for Application le versioni A2003: dalla versione A2007 sarà
addirittura free e quindi decade anche il costo. Questo tool ti permette di
distribuire un ambiente runtime che permette di far girare la tua
applicazione a costo zero. C'è un inconveniente A2003 non gira su S.O.
precedenti a W2000 quindi ti serve Access xp developer. Lo potrest trovare
anche su ebay a costi irrisori.
E' lo stesso che avviene con VB, cmq devi distribuire il runtime VB.
>
> 2. STABILITA' -  Ho la sensazione che un programma Access, anche
> perchè dipende da una sovrastruttura Office, sia meno stabile e meno
> affidabile, specie quando, con il passar del tempo, le 250 casse
> cominceranno a differenziarsi come versione sia di Office che di
> sistema operativo Windows, cosa che sicuramente si verificherà a causa
> di rotture e guasti sia dell'hardware che del software, che
> richiederanno il ripristino del sistema operativo Windows e di Office
> nella versione più aggiornata.  Un .exe mi sembra non debba risentire
> di questo.
Tu confondi Access come backend e Access come Front End.
Ti suggerisco quindi SQL Express (N.B. GRATUITO) come database locale e
Access come GUI cioè maschere, query, report e codice.
>
> 3. COMPILAZIONE - Un programma .mdb è un programma interpretato in
> fase di esecuzione. Anche questo fatto mi pare negativo rispetto ad un
> programma compilato. - Inoltre un .exe è sicuramente inaccessibile
> come codice all'utente. Un .mdb, anche se trasformato in .mde, mi dà
> la sensazione che qualcuno delle 250 persone che dovranno usarlo,
> possa in qualche modo manometterlo o guastarlo.
Sensazione errata. Il P-code generato dal'mde è ininterpretabile. L'anno
scorso abbiamo assistito ad un esperimento di un geniaccio di access,
credimi sicuramente non alla portata di tutti e cmq riuscirebbe a crackare
anche un programma VB o altro, ma aveva bisogno di alcuni accorgimenti,
tolti i quali (e nessuno li mette normalmente quando sviluppa) l'mde è
ancora tranquillamente inviolabile al pari di un programma compilato.
>
> 4. AMPIEZZA - Un programma compilato è più piccolo. Nel mio caso il
> programma Access di Gestione della Vendita, una volta finito, mi
> aspetto che sarà grande almeno da 5 a 7 MB. Quindi trasmettere le
> nuove versioni a tutti i negozi richiederà più tempo (e minor
> sicurezza di trasmissione sulle linee telefoniche), anche se una
> versione .mde potrebbe essere più piccola, credo un 10-20% in meno.
beh questo non è verissimo, potresti spezzetare l'applicazione in diversi db
a seconda di quello che ti serve e sostituire di volta in volta solo ciò che
ti serve
>
> 5. DATA-BASE. - Questo non mi pare un problema, anche in una soluzione
> Access. Infatti mi sono premurato, prima ancora di realizzare la parte
> grafica e propriamente elaborativa del programma, di provare i tempi
> di risposta nell'accesso al data-base. Questi devono essere molto
> veloci, dato che la lettura del barcode dei prodotti avviene
> consecutivamente, un prodotto dopo l'altro, a notevole velocità, e per
> ogni lettura occorre accedere agli archivi dei prodotti e mandare a
> monitor la risposta con prezzo e condizioni. Uno di questi archivi è
> molto grande (circa 2.500.000 record). Ma ho constatato che, purchè
> siano impostate correttamente le chiavi di ricerca dei record, i tempi
> di risposta  sono del tutto soddisfacenti.
>
SQL Express appunto
> 5.a - Scegliendo un altro tool di sviluppo al posto di Access si pone
> anche  il problema di scegliere il data-base.  Però non vorrei cadere
> dalla padella nella brace. Scegliendo un data-base tipo SQLServer mi
> pare che avrei di nuovo problemi sia di licenza (per 250 casse circa)
> che di complessità. Il data-base .mdb è molto più semplice da
> installare e da trattare, rispetto ad un SQLServer, secondo me.
Convinzione errata. Il 3 maggio ci sarà un webcast su questa soluzione e
vedrai come è semplice. Tra l'altro alla Cisa, Giorgio farà un intervento su
Access+ SQL Server + ODBC, che ti consiglio di seguire
>
> 5.b - Scegliendo invece di conservare, come data-base, un .mdb,
> risponde al vero che in questo caso, senza programma elaborativo
> Access, non è richiesta la licenza? Mi dicono che un eventuale
> programma, p. es. in Visual Basic, accederebbe all'.mdb tramite MDAC
> (Microsoft Data Access Components - ODBC), e ciò non comporta licenza
> Access.
Questo è vero, ma il db access non è consigliabile
>
> Aggiungo che l'idea di voler convertire l'attuale pacchetto tramite
> Access (e non tramite un altro tool di sviluppo) deriva anche dal
> fatto che il Centro Elaborazione Dati dell'azienda attualmente è
> autonomo nella manutenzione dell'attuale programma Clipper e vuole
> continuare ad esserlo in futuro. I componenti del CED possiedono una
> buona conoscenza di Access (oltre che di Clipper) ma non di altri
> tools di sviluppo.
Perfetto, tra l'altro loro avrebbero anche il runtime e quindi eventuali
nuove macchine sarebbe subito licenziate.
>
> Tuttavia, se lo sviluppo in Access si dimostrasse una soluzione non
> valida, secondo me insistere su questa possibilità potrebbe essere
> pericoloso per i problemi che ne deriverebbero in futuro.
Ti posso rassicurare con comprensibile tranquillità. Poi bisogna capire cosa
sai/sanno fare con access
>
> Se le Vostre considearzioni saranno negative nei confronti di Access,
> suggerirò loro di utilizzare i 55.000 euro risparmiati dalla rinuncia
> alle licenze Access per farsi aiutare a convertire l'attuale programma
> tramite il tool scelto, e contemporaneamente di acquisire autonomia
> nell'uso del medesimo sia con corsi che con manuali.
>
> Mi scuso per la prolissità e Vi ringrazio.
Se hai problemi o dubbi continuare a chiedere
--
--
Massimiliano Amendola
www.accessgroup.it
Cisa - Conferenza Italiana Sviluppatori Access


text:
Il Wed, 11 Apr 2007 16:34:09 +0200, Ludus <
lu...@tele2.it
> ha scritto:
>(.....)
>1. LICENZE - Un programma .mdb richiede che su tutte le casse (circa
>250)  debba  essere installato Office/Access. Ciò comporta anzitutto
>un problema di costo delle licenze. Se una licenza costa circa 220
>euro, per 250 casse si ottiene un totale di 55.000 euro. Soldi che
>realizzando il programma tramite un altro tool in grado di ottenere un
>.exe sarebbero risparmiati.
No.
Se usi i tool di sviluppo di Office puoi distribuire il runtime di Access insieme alla tua applicazione, senza pagare
alcuna licenza aggiuntiva e senza preccuparti della presenza di Office e/o Access sul computer di destinazione.
>
>2. STABILITA' -  Ho la sensazione che un programma Access, anche
>perchè dipende da una sovrastruttura Office, sia meno stabile e meno
>affidabile, specie quando, con il passar del tempo, le 250 casse
>cominceranno a differenziarsi come versione sia di Office che di
>sistema operativo Windows, cosa che sicuramente si verificherà a causa
>di rotture e guasti sia dell'hardware che del software, che
>richiederanno il ripristino del sistema operativo Windows e di Office
>nella versione più aggiornata.  Un .exe mi sembra non debba risentire
>di questo.
No.
Se l'applicazione è ben ingegnerizzata e progettata, se non fai uso di componenti esterne (ocx ecc.) è stabile nè più nè
meno di un programma compilato.
>
>3. COMPILAZIONE - Un programma .mdb è un programma interpretato in
>fase di esecuzione. Anche questo fatto mi pare negativo rispetto ad un
>programma compilato. - Inoltre un .exe è sicuramente inaccessibile
>come codice all'utente. Un .mdb, anche se trasformato in .mde, mi dà
>la sensazione che qualcuno delle 250 persone che dovranno usarlo,
>possa in qualche modo manometterlo o guastarlo.
No. In ogni caso (è successo molto raramente) basta ripristinare la copia originale.
Magari ogni volta all'accensione del pc.
>4. AMPIEZZA - Un programma compilato è più piccolo. Nel mio caso il
>programma Access di Gestione della Vendita, una volta finito, mi
>aspetto che sarà grande almeno da 5 a 7 MB. Quindi trasmettere le
>nuove versioni a tutti i negozi richiederà più tempo (e minor
>sicurezza di trasmissione sulle linee telefoniche), anche se una
>versione .mde potrebbe essere più piccola, credo un 10-20% in meno.
Dipende anche dalla frequenza degli aggiornamenti.
Perchè non collegare i negozi via ADSL all'AS/400 su VPN ?
>5. DATA-BASE. - Questo non mi pare un problema, anche in una soluzione
>Access. Infatti mi sono premurato, prima ancora di realizzare la parte
>grafica e propriamente elaborativa del programma, di provare i tempi
>di risposta nell'accesso al data-base. Questi devono essere molto
>veloci, dato che la lettura del barcode dei prodotti avviene
>consecutivamente, un prodotto dopo l'altro, a notevole velocità, e per
>ogni lettura occorre accedere agli archivi dei prodotti e mandare a
>monitor la risposta con prezzo e condizioni. Uno di questi archivi è
>molto grande (circa 2.500.000 record). Ma ho constatato che, purchè
>siano impostate correttamente le chiavi di ricerca dei record, i tempi
>di risposta  sono del tutto soddisfacenti.
>
>5.a - Scegliendo un altro tool di sviluppo al posto di Access si pone
>anche  il problema di scegliere il data-base.  Però non vorrei cadere
>dalla padella nella brace. Scegliendo un data-base tipo SQLServer mi
>pare che avrei di nuovo problemi sia di licenza (per 250 casse circa)
>che di complessità. Il data-base .mdb è molto più semplice da
>installare e da trattare, rispetto ad un SQLServer, secondo me.
Nessun problema di licenza: esiste la versione Express che è addirittura free.
Per la facilità d'uso ... basta un minimo di familiarità.
>5.b - Scegliendo invece di conservare, come data-base, un .mdb,
>risponde al vero che in questo caso, senza programma elaborativo
>Access, non è richiesta la licenza? Mi dicono che un eventuale
>programma, p. es. in Visual Basic, accederebbe all'.mdb tramite MDAC
>(Microsoft Data Access Components - ODBC), e ciò non comporta licenza
>Access.
Vedi risposta la punto 1.
>Aggiungo che l'idea di voler convertire l'attuale pacchetto tramite
>Access (e non tramite un altro tool di sviluppo) deriva anche dal
>fatto che il Centro Elaborazione Dati dell'azienda attualmente è
>autonomo nella manutenzione dell'attuale programma Clipper e vuole
>continuare ad esserlo in futuro. I componenti del CED possiedono una
>buona conoscenza di Access (oltre che di Clipper) ma non di altri
>tools di sviluppo.
>
>Tuttavia, se lo sviluppo in Access si dimostrasse una soluzione non
>valida, secondo me insistere su questa possibilità potrebbe essere
>pericoloso per i problemi che ne deriverebbero in futuro.
Mi lascia perplesso il fatto che tu non conosca Visual Basic.
Con Access da solo, senza conoscere VBA (che di fatto è una versione di Visual Basic), si va veramente poco lontano ...
>Se le Vostre considearzioni saranno negative nei confronti di Access,
>suggerirò loro di utilizzare i 55.000 euro risparmiati dalla rinuncia
>alle licenze Access per farsi aiutare a convertire l'attuale programma
>tramite il tool scelto, e contemporaneamente di acquisire autonomia
>nell'uso del medesimo sia con corsi che con manuali.
>
>Mi scuso per la prolissità e Vi ringrazio.
Vincenzo Turturro
---------------------------------------------
il sito comune di it.comp.appl.access:
http://www.sitocomune.com/
---------------------------------------------
E quello di it.comp.as400
http://www.faq400.com/
---------------------------------------------


text:
... OMISSIS ...
>
>Mi lascia perplesso il fatto che tu non conosca Visual Basic.
>Con Access da solo, senza conoscere VBA (che di fatto è una versione di Visual Basic), si va veramente poco lontano ...
>
>Vincenzo Turturro
Non mi sono spiegato bene. Non conosco il tool di sviluppo Visual
Basic, ma il VBA lo uso a piene mani nel realizzare un programma
Access. Sono d'accordo con te che senza VBA non si fa un granchè.
Per il resto per ora grazie.
Leggerò con calma le tue osservazioni e poi mi farò risentire.
Ciao



text:
... OMISSIS ...
>
>Se hai problemi o dubbi continuare a chiedere
>--
Grazie per ora.
Leggerň con attenzione e mi informerň su quanto mi hai detto, poi mi
farň sicuramente risentire.
Ciao


text:
On Wed, 11 Apr 2007 17:20:06 +0200, "MA"
<
mas...@massimilianoamendola.it
> wrote:
>Ludus wrote:
>
>> Chiedo aiuto agli esperti. Ho provato a cercare nel Sito Comune ma non
>> ho trovato un approfondimento sull'argomento.
>
>Ciao Ludus,
>la tua analisi è esaustiva ma parte da conoscenze del prodotto Access e
>della sua gestione delle licenze errato. Ti consiglio di leggere l'articolo
>dedicato
>su
www.accessgroup.it
Su Accessgroup ho trovato il tuo articolo "Posso distribuire il
runtime?". Ti riferisci a questo? Runtime e Office Developer? E' tutto
un po' complicato, e mi è parso che ci siano delle limitazioni... ma
approfondirò senz'altro, anche se è probabile che avrò bisogno di
qualche altro aiutino.
>Access può essere la tua soluzione, tranquillamente, con dei però.
>
>Primo: Access deve essere solo il front end, devi usare SQL Server come
>Backend.
>A questo punto non preoccuparti, il tutto ti può costare meno di 500 euro
>(con un però)
Riprendo l'argomento più sotto.
>ma rispondiamo punto per punto
>
>[Cut]
>
>> I programmi di COMUNICAZIONE CON LA SEDE, che ha come computer
>> gestionale un AS/400, ricevono nottetempo le modifiche ai data-base
>> degli articoli e dei relativi prezzi e sconti, e trasmettono alla sede
>> le vendite del giorno precedente.
>>
>[CUT]
>
>Qui devi scegliere se usare AS400 collegato come Backend per tutti o usare
>un db SQL, uno solo, anche nella versione Express (cioè free) che curi il
>collegamento tra i client e AS400. Io ti suggerisco quest'ultima soluzione
>anche perchè così esponi ad internet un db di passaggio e non il db server
>(è il principio delle carte di credito prepagate, se interettano quelle il
>danno è limitatissimo)
>
D'accordo. Per l'SQL riprendo più avanti.
>
>>
>> 1. LICENZE - Un programma .mdb richiede che su tutte le casse (circa
>> 250)  debba  essere installato Office/Access. Ciò comporta anzitutto
>> un problema di costo delle licenze. Se una licenza costa circa 220
>> euro, per 250 casse si ottiene un totale di 55.000 euro. Soldi che
>> realizzando il programma tramite un altro tool in grado di ottenere un
>> .exe sarebbero risparmiati.
>
>Esiste un tool che si chiama Developer kit fino ad Access xp e Visual Studio
>Tools for Application le versioni A2003: dalla versione A2007 sarà
>addirittura free e quindi decade anche il costo. Questo tool ti permette di
>distribuire un ambiente runtime che permette di far girare la tua
>applicazione a costo zero. C'è un inconveniente A2003 non gira su S.O.
>precedenti a W2000 quindi ti serve Access xp developer. Lo potrest trovare
>anche su ebay a costi irrisori.
>E' lo stesso che avviene con VB, cmq devi distribuire il runtime VB.
Come sopra: devo capire bene tutto ciò.
>>
>> 2. STABILITA' -  Ho la sensazione che un programma Access, anche
>> perchè dipende da una sovrastruttura Office, sia meno stabile e meno
>> affidabile, specie quando, con il passar del tempo, le 250 casse
>> cominceranno a differenziarsi come versione sia di Office che di
>> sistema operativo Windows, cosa che sicuramente si verificherà a causa
>> di rotture e guasti sia dell'hardware che del software, che
>> richiederanno il ripristino del sistema operativo Windows e di Office
>> nella versione più aggiornata.  Un .exe mi sembra non debba risentire
>> di questo.
>
>Tu confondi Access come backend e Access come Front End.
>Ti suggerisco quindi SQL Express (N.B. GRATUITO) come database locale e
>Access come GUI cioè maschere, query, report e codice.
>
SQL Express è un subset di SQL Server o è un'altra cosa?
Quel che non capisco è perchè sei così tassativo nel consigliarmi SQL
(Express o Server), al posto della gestione data-base di Access. Io
sono anni che uso il db back-end di Access (con il motore Jet, si dice
così?) senza problemi. E' efficiente e sicuro. Non ho mai perso un
record. Pur conoscendo pochissimo il SQL Server, questo mi sembra
molto più complicato.
Domande conseguenti. Ammesso che io abbia Access come front-end e un
SQL (Express o Server) come back-end (così come da te consigliato),
avrò la stessa facilità di accesso alle tabelle? Mi riferisco in
particolare alla possibilità di costruire comandi sql tamite la
modalità grafica così facile e potente di Access nel predisporre le
"query"? E avrò le stesse ottime performances negli accessi ai dati?
Dovrò accedere all'SQL tramite ODBC? Non peggiorano i tempi di
risposta?  Non mi impegolerò nelle cosiddette (non mi viene la parola)
???-procedures?
>>
>> 3. COMPILAZIONE - Un programma .mdb è un programma interpretato in
>> fase di esecuzione. Anche questo fatto mi pare negativo rispetto ad un
>> programma compilato. - Inoltre un .exe è sicuramente inaccessibile
>> come codice all'utente. Un .mdb, anche se trasformato in .mde, mi dà
>> la sensazione che qualcuno delle 250 persone che dovranno usarlo,
>> possa in qualche modo manometterlo o guastarlo.
>
>Sensazione errata. Il P-code generato dal'mde è ininterpretabile. L'anno
>scorso abbiamo assistito ad un esperimento di un geniaccio di access,
>credimi sicuramente non alla portata di tutti e cmq riuscirebbe a crackare
>anche un programma VB o altro, ma aveva bisogno di alcuni accorgimenti,
>tolti i quali (e nessuno li mette normalmente quando sviluppa) l'mde è
>ancora tranquillamente inviolabile al pari di un programma compilato.
D'accordo. Ciò mi tranquillizza.
>
>>
>> 4. AMPIEZZA - Un programma compilato è più piccolo. Nel mio caso il
>> programma Access di Gestione della Vendita, una volta finito, mi
>> aspetto che sarà grande almeno da 5 a 7 MB. Quindi trasmettere le
>> nuove versioni a tutti i negozi richiederà più tempo (e minor
>> sicurezza di trasmissione sulle linee telefoniche), anche se una
>> versione .mde potrebbe essere più piccola, credo un 10-20% in meno.
>
>beh questo non è verissimo, potresti spezzetare l'applicazione in diversi db
>a seconda di quello che ti serve e sostituire di volta in volta solo ciò che
>ti serve
Anche qui temo di essere impreparato. Oggi ho fatto anche qualche
ricerca nell'Help in linea, ma non ho trovato quanto cercavo. In poche
parole, se apro un programma base, che deve lanciare di volta in volta
uno dei diversi pezzetti come tu mi consigli, come si può fare? C'è un
comando dipo Shell o simile? Call? O che so?
>
>>
>> 5. DATA-BASE. - Questo non mi pare un problema, anche in una soluzione
>> Access. Infatti mi sono premurato, prima ancora di realizzare la parte
>> grafica e propriamente elaborativa del programma, di provare i tempi
>> di risposta nell'accesso al data-base. Questi devono essere molto
>> veloci, dato che la lettura del barcode dei prodotti avviene
>> consecutivamente, un prodotto dopo l'altro, a notevole velocità, e per
>> ogni lettura occorre accedere agli archivi dei prodotti e mandare a
>> monitor la risposta con prezzo e condizioni. Uno di questi archivi è
>> molto grande (circa 2.500.000 record). Ma ho constatato che, purchè
>> siano impostate correttamente le chiavi di ricerca dei record, i tempi
>> di risposta  sono del tutto soddisfacenti.
>>
>
>SQL Express appunto
Ah, ma allora insisti... (Non so fare la faccina scherzosa).
>
>> 5.a - Scegliendo un altro tool di sviluppo al posto di Access si pone
>> anche  il problema di scegliere il data-base.  Però non vorrei cadere
>> dalla padella nella brace. Scegliendo un data-base tipo SQLServer mi
>> pare che avrei di nuovo problemi sia di licenza (per 250 casse circa)
>> che di complessità. Il data-base .mdb è molto più semplice da
>> installare e da trattare, rispetto ad un SQLServer, secondo me.
>
>Convinzione errata. Il 3 maggio ci sarà un webcast su questa soluzione e
>vedrai come è semplice. Tra l'altro alla Cisa, Giorgio farà un intervento su
>Access+ SQL Server + ODBC, che ti consiglio di seguire
Che cosa è il "webcast" e come posso seguirlo il 3 maggio? Anche
l'intervento di Giorgio alla Cisa, dov'è?
>
>>
>> 5.b - Scegliendo invece di conservare, come data-base, un .mdb,
>> risponde al vero che in questo caso, senza programma elaborativo
>> Access, non è richiesta la licenza? Mi dicono che un eventuale
>> programma, p. es. in Visual Basic, accederebbe all'.mdb tramite MDAC
>> (Microsoft Data Access Components - ODBC), e ciò non comporta licenza
>> Access.
>
>Questo è vero, ma il db access non è consigliabile
Repetita juvant...
>
>>
>> Aggiungo che l'idea di voler convertire l'attuale pacchetto tramite
>> Access (e non tramite un altro tool di sviluppo) deriva anche dal
>> fatto che il Centro Elaborazione Dati dell'azienda attualmente è
>> autonomo nella manutenzione dell'attuale programma Clipper e vuole
>> continuare ad esserlo in futuro. I componenti del CED possiedono una
>> buona conoscenza di Access (oltre che di Clipper) ma non di altri
>> tools di sviluppo.
>
>Perfetto, tra l'altro loro avrebbero anche il runtime e quindi eventuali
>nuove macchine sarebbe subito licenziate.
OK.
>
>>
>> Tuttavia, se lo sviluppo in Access si dimostrasse una soluzione non
>> valida, secondo me insistere su questa possibilità potrebbe essere
>> pericoloso per i problemi che ne deriverebbero in futuro.
>
>Ti posso rassicurare con comprensibile tranquillità. Poi bisogna capire cosa
>sai/sanno fare con access
Ne ho parlato con il Capo Centro e l'ho visto disponibilissimo. Tra
parentesi è lui che ha scritto tutta l'applicazione in Clipper ed è
uno in gamba.
>
>>
>> Se le Vostre considearzioni saranno negative nei confronti di Access,
>> suggerirò loro di utilizzare i 55.000 euro risparmiati dalla rinuncia
>> alle licenze Access per farsi aiutare a convertire l'attuale programma
>> tramite il tool scelto, e contemporaneamente di acquisire autonomia
>> nell'uso del medesimo sia con corsi che con manuali.
>>
>> Mi scuso per la prolissità e Vi ringrazio.
>
>Se hai problemi o dubbi continuare a chiedere
Come vedi...
Ciao e grazie.
>--


text:
On Wed, 11 Apr 2007 17:32:06 +0200, "VT @ home" <
V...@home.it
> wrote:
>Il Wed, 11 Apr 2007 16:34:09 +0200, Ludus <
lu...@tele2.it
> ha scritto:
>>(.....)
>
>>1. LICENZE - Un programma .mdb richiede che su tutte le casse (circa
>>250)  debba  essere installato Office/Access. Ciò comporta anzitutto
>>un problema di costo delle licenze. Se una licenza costa circa 220
>>euro, per 250 casse si ottiene un totale di 55.000 euro. Soldi che
>>realizzando il programma tramite un altro tool in grado di ottenere un
>>.exe sarebbero risparmiati.
>
>No.
>Se usi i tool di sviluppo di Office puoi distribuire il runtime di Access insieme alla tua applicazione, senza pagare
>alcuna licenza aggiuntiva e senza preccuparti della presenza di Office e/o Access sul computer di destinazione.
>
Anche "MA" di Accessgroup ha risposto al mio quesito più o meno allo
stesso modo.  Cercherò di approfondire bene e se non ce la faccio da
solo tornerò a chiedere aiuto.
>>
>>2. STABILITA' -  Ho la sensazione che un programma Access, anche
>>perchè dipende da una sovrastruttura Office, sia meno stabile e meno
>>affidabile, specie quando, con il passar del tempo, le 250 casse
>>cominceranno a differenziarsi come versione sia di Office che di
>>sistema operativo Windows, cosa che sicuramente si verificherà a causa
>>di rotture e guasti sia dell'hardware che del software, che
>>richiederanno il ripristino del sistema operativo Windows e di Office
>>nella versione più aggiornata.  Un .exe mi sembra non debba risentire
>>di questo.
>
>No.
>Se l'applicazione è ben ingegnerizzata e progettata, se non fai uso di componenti esterne (ocx ecc.) è stabile nè più nè
>meno di un programma compilato.
D'accordo, credo alla tua esperienza che mi tranquillizza.
>
>>
>>3. COMPILAZIONE - Un programma .mdb è un programma interpretato in
>>fase di esecuzione. Anche questo fatto mi pare negativo rispetto ad un
>>programma compilato. - Inoltre un .exe è sicuramente inaccessibile
>>come codice all'utente. Un .mdb, anche se trasformato in .mde, mi dà
>>la sensazione che qualcuno delle 250 persone che dovranno usarlo,
>>possa in qualche modo manometterlo o guastarlo.
>
>No. In ogni caso (è successo molto raramente) basta ripristinare la copia originale.
>Magari ogni volta all'accensione del pc.
Idem come sopra.
>
>>4. AMPIEZZA - Un programma compilato è più piccolo. Nel mio caso il
>>programma Access di Gestione della Vendita, una volta finito, mi
>>aspetto che sarà grande almeno da 5 a 7 MB. Quindi trasmettere le
>>nuove versioni a tutti i negozi richiederà più tempo (e minor
>>sicurezza di trasmissione sulle linee telefoniche), anche se una
>>versione .mde potrebbe essere più piccola, credo un 10-20% in meno.
>
>Dipende anche dalla frequenza degli aggiornamenti.
>Perchè non collegare i negozi via ADSL all'AS/400 su VPN ?
In effetti i negozi sono già collegati cia ADSL, e quindi 6 o 7 mega
alla fin fine non sono poi un granchè.
>
>>5. DATA-BASE. - Questo non mi pare un problema, anche in una soluzione
>>Access. Infatti mi sono premurato, prima ancora di realizzare la parte
>>grafica e propriamente elaborativa del programma, di provare i tempi
>>di risposta nell'accesso al data-base. Questi devono essere molto
>>veloci, dato che la lettura del barcode dei prodotti avviene
>>consecutivamente, un prodotto dopo l'altro, a notevole velocità, e per
>>ogni lettura occorre accedere agli archivi dei prodotti e mandare a
>>monitor la risposta con prezzo e condizioni. Uno di questi archivi è
>>molto grande (circa 2.500.000 record). Ma ho constatato che, purchè
>>siano impostate correttamente le chiavi di ricerca dei record, i tempi
>>di risposta  sono del tutto soddisfacenti.
>>
>>5.a - Scegliendo un altro tool di sviluppo al posto di Access si pone
>>anche  il problema di scegliere il data-base.  Però non vorrei cadere
>>dalla padella nella brace. Scegliendo un data-base tipo SQLServer mi
>>pare che avrei di nuovo problemi sia di licenza (per 250 casse circa)
>>che di complessità. Il data-base .mdb è molto più semplice da
>>installare e da trattare, rispetto ad un SQLServer, secondo me.
>
>Nessun problema di licenza: esiste la versione Express che è addirittura free.
>Per la facilità d'uso ... basta un minimo di familiarità.
Ho commentato e chiesto ulteriori spiegazioni sull'argomento a "MA" di
Accessgroup che ha risposto ai miei quesiti, come gentilmente hai
fatto tu. Va tutto così liscio con SQL Express? Se è così, bene. Però
non riesco a capire perchè entrambi mi sconsigliate il db back-end di
Access che va così bene!... ed è così facile da usare!...
>
>>5.b - Scegliendo invece di conservare, come data-base, un .mdb,
>>risponde al vero che in questo caso, senza programma elaborativo
>>Access, non è richiesta la licenza? Mi dicono che un eventuale
>>programma, p. es. in Visual Basic, accederebbe all'.mdb tramite MDAC
>>(Microsoft Data Access Components - ODBC), e ciò non comporta licenza
>>Access.
>
>Vedi risposta la punto 1.
OK.
>
>>Aggiungo che l'idea di voler convertire l'attuale pacchetto tramite
>>Access (e non tramite un altro tool di sviluppo) deriva anche dal
>>fatto che il Centro Elaborazione Dati dell'azienda attualmente è
>>autonomo nella manutenzione dell'attuale programma Clipper e vuole
>>continuare ad esserlo in futuro. I componenti del CED possiedono una
>>buona conoscenza di Access (oltre che di Clipper) ma non di altri
>>tools di sviluppo.
>
>>
>>Tuttavia, se lo sviluppo in Access si dimostrasse una soluzione non
>>valida, secondo me insistere su questa possibilità potrebbe essere
>>pericoloso per i problemi che ne deriverebbero in futuro.
>
>Mi lascia perplesso il fatto che tu non conosca Visual Basic.
>Con Access da solo, senza conoscere VBA (che di fatto è una versione di Visual Basic), si va veramente poco lontano ...
Non mi ero spiegato bene. Su questo argomento ti ho già risposto.



text:
Ludus wrote:
> On Wed, 11 Apr 2007 17:20:06 +0200, "MA"
> <
mas...@massimilianoamendola.it
> wrote:
>
>> Ludus wrote:
>>
>>> Chiedo aiuto agli esperti. Ho provato a cercare nel Sito Comune ma
>>> non ho trovato un approfondimento sull'argomento.
>>
>> Ciao Ludus,
>
> Su Accessgroup ho trovato il tuo articolo "Posso distribuire il
> runtime?". Ti riferisci a questo? Runtime e Office Developer? E' tutto
> un po' complicato, e mi č parso che ci siano delle limitazioni... ma
> approfondirņ senz'altro, anche se č probabile che avrņ bisogno di
> qualche altro aiutino.
Sģ quello. Non ci sono grandi limitazioni. L'unica č la scelta della
versione, se hai pc con win '98 devi trovare xp developer.
> SQL Express č un subset di SQL Server o č un'altra cosa?
> Quel che non capisco č perchč sei cosģ tassativo nel consigliarmi SQL
> (Express o Server), al posto della gestione data-base di Access. Io
> sono anni che uso il db back-end di Access (con il motore Jet, si dice
> cosģ?) senza problemi. E' efficiente e sicuro. Non ho mai perso un
> record. Pur conoscendo pochissimo il SQL Server, questo mi sembra
> molto pił complicato.
SQL Express č una versione limitata di Sql. E' la versione aggiornata di
MSDE, ma diverso nelle limitazioni. La prima pił importante: MSDE deteriora
le prestazioni dopo 5 utenti contemporanei (in pratica era solo un modo per
approcciarsi a SQL, anche se ho visto applicazioni che funzionano benissimo
con MSDE anche con molti + utenti); con SQL Express 2005 no nhai problemi
del genere, hai solo la limitazione di lavorare su di 1 Gb di Ram (anche se
il server ne montasse di pił) e con un solo processsore (anche qui a
dispetto della configurazione del server); inoltre un db Sql č al massimo di
4 GB (access lo č di 2 GB). Nel tuo caso queste limitazioni non sarebbero
sofferte, perchč SQL č slo il collettore per rversare tutto sul server
AS400, quindi lo riempi e l svuoti come vuoi.
Anche io lavoro da anni con gli MDB, ma visto la qualitą del servizio di SQL
e l'esiguitą di inconvenienti (quasi zero) non ha pił senso. Un altro motivo
č la possibilitą con sql di creare una rete geografica attraverso una VPN
(con Access č improponibile): metti che vuoi fare una ricerca tipo come č la
giacenza in real time di quel prodotto? In un attimo ce l'hai e la verifichi
con la giacenza che riulta sul server.
>
> Domande conseguenti. Ammesso che io abbia Access come front-end e un
> SQL (Express o Server) come back-end (cosģ come da te consigliato),
> avrņ la stessa facilitą di accesso alle tabelle? Mi riferisco in
> particolare alla possibilitą di costruire comandi sql tamite la
> modalitą grafica cosģ facile e potente di Access nel predisporre le
> "query"? E avrņ le stesse ottime performances negli accessi ai dati?
> Dovrņ accedere all'SQL tramite ODBC? Non peggiorano i tempi di
> risposta?  Non mi impegolerņ nelle cosiddette (non mi viene la parola)
> ???-procedures?
Sģ, assolutamente la stessa. Tu lavori in ambiente Access e quindi non hai
problemi. In pił hai la possibilitą di usare le query PT cioč delle query
che lvorano diettamente sul server e quindi spaventosamente pił veloci.
I driver ODBC assolutamente non rallentano le prestazioni, ovvio che perņ
devi costruire bene il tutto.
>>
>> beh questo non č verissimo, potresti spezzetare l'applicazione in
>> diversi db a seconda di quello che ti serve e sostituire di volta in
>> volta solo ciņ che ti serve
>
> Anche qui temo di essere impreparato. Oggi ho fatto anche qualche
> ricerca nell'Help in linea, ma non ho trovato quanto cercavo. In poche
> parole, se apro un programma base, che deve lanciare di volta in volta
> uno dei diversi pezzetti come tu mi consigli, come si puņ fare? C'č un
> comando dipo Shell o simile? Call? O che so?
L'idea č quella di creare applicazioni separate. Una per il FE delle casse,
uno o pił per gli uffici, una per il magazzino, etc. Poi ti crei una
applicazione di navigazione e attraverso quella gestisci il tutto. ovvio che
cosģ puoi cambiare i pezzi che credi.
Oppure, io faccio cosģ, creo dei Service pack, dei piccoli db che lanciati,
cancellano,  sostituiscono o aggiungono oggetti tipo form, moduli, report o
altro, oppure aggiornano valori. Quindi tu invii quest aggiornamenti e loro
fanno tutto dopo aver fatto un bel backup della versione da aggiornare.
ma da qualche parte ho letto che hai l'adsl, quindi non hai nessunissimo
problema. Tra l'altro con la famosa VPN (o anche usando software free come
Hamachi) puoi fare anche assistenza remota e cioč dal tuo ufficio sistemi il
problema dell'applicazione che gira a Canicattģ, io ho mie applicazioni che
girano ad Hong Kong e credimi non č che vado una settimana sģ ed una no.
>> SQL Express appunto
>
> Ah, ma allora insisti... (Non so fare la faccina scherzosa).
;-)
>> Convinzione errata. Il 3 maggio ci sarą un webcast su questa
>> soluzione e vedrai come č semplice. Tra l'altro alla Cisa, Giorgio
>> farą un intervento su Access+ SQL Server + ODBC, che ti consiglio di
>> seguire
>
> Che cosa č il "webcast" e come posso seguirlo il 3 maggio? Anche
> l'intervento di Giorgio alla Cisa, dov'č?
I Webcast sono dimostrazioni online
http://www.microsoft.com/italy/eventi/default.mspx
tra non molto verrą pubblicato anche l'appuntamento di cui ti parlavo. Per
seguirli ti basta Windows Media Player.
La Cisa č una conferenza che si terrą a Milano, info le trovi su
www.accessgroup.it
>>> Tuttavia, se lo sviluppo in Access si dimostrasse una soluzione non
>>> valida, secondo me insistere su questa possibilitą potrebbe essere
>>> pericoloso per i problemi che ne deriverebbero in futuro.
>>
>> Ti posso rassicurare con comprensibile tranquillitą. Poi bisogna
>> capire cosa sai/sanno fare con access
>
> Ne ho parlato con il Capo Centro e l'ho visto disponibilissimo. Tra
> parentesi č lui che ha scritto tutta l'applicazione in Clipper ed č
> uno in gamba.
Quindi conoscerą bene la situazione e farą una buona analisi.
Se hai bisogno di ulteriori rassicurazioni (morali, quelle tecniche le
continuiamo qui) puoi scrivermi in privato e ci mettiamo in contatto via
Skype.
;-)



text:
On Fri, 13 Apr 2007 10:13:38 +0200, "MA"
<
mas...@massimilianoamendola.it
> wrote:
... Omissis ...
>
>Se hai bisogno di ulteriori rassicurazioni (morali, quelle tecniche le
>continuiamo qui) puoi scrivermi in privato e ci mettiamo in contatto via
>Skype.
>;-)
>
OK. Grazie. Digerisco piano piano tutte le informazioni che mi hai
dato e poi mi faccio risentire.
Però una cosa te la chiedo subito, se hai voglia e tempo: Non sono
ancora riuscito a capire il motivo reale, tecnico o di altra natura,
perchè tu (e altri) insistete nel consigliarmi l'uso di una base dati
di tipo SQL Server (o SQL Express) anzichè il database di Access.
Quali sicuri vantaggi offre l'SQL? E' più stabile? E' più performante?
Offre maggiori possibilità di accesso? E' più compatto?
Se non riesco a convincermi della convenienza di usare SQL, perchè
dovrei abbandonare il database di Access che finora non mi ha dato
alcun problema?
Saluti.


text:
Il Sun, 15 Apr 2007 12:35:33 +0200, Ludus <
lu...@tele2.it
> ha scritto:
>(.....)
>On Fri, 13 Apr 2007 10:13:38 +0200, "MA"
><
mas...@massimilianoamendola.it
> wrote:
>
>... Omissis ...
>>
>>Se hai bisogno di ulteriori rassicurazioni (morali, quelle tecniche le
>>continuiamo qui) puoi scrivermi in privato e ci mettiamo in contatto via
>>Skype.
>>;-)
>>
>
>OK. Grazie. Digerisco piano piano tutte le informazioni che mi hai
>dato e poi mi faccio risentire.
>
>Però una cosa te la chiedo subito, se hai voglia e tempo: Non sono
>ancora riuscito a capire il motivo reale, tecnico o di altra natura,
>perchè tu (e altri) insistete nel consigliarmi l'uso di una base dati
>di tipo SQL Server (o SQL Express) anzichè il database di Access.
>
>Quali sicuri vantaggi offre l'SQL? E' più stabile? E' più performante?
>Offre maggiori possibilità di accesso? E' più compatto?
Perchè è un RDBMS vero, quindi offre pieno supporto alle transazioni, alle autorizzazioni utente, alle stored procedure,
ai trigger ...
Alcune di queste funzionalità sono presenti anche in Access, ma implementate in maniera più "artigianale", tenuto conto
anche del fatto che Access è nato come DBMS per uso personale, mentre SQL è nato come risposta ad Oracle in ambito
aziendale.
>
>Se non riesco a convincermi della convenienza di usare SQL, perchè
>dovrei abbandonare il database di Access che finora non mi ha dato
>alcun problema?
>
>Saluti.
>



text:
Con riferimento ai suggerimenti che con pazienza mi sono stati forniti
da  MA (Massimiliano Amendola) e da VT (Vincenzo Turturro), provo a
riepilogare quanto ho appreso, salvo ulteriori precisazioni da parte
di MA e VT  e della comunità:
1. Non è vero che sia necessario installare Office/Access su tutti i
computer che dovranno far girare l'applicazione Access, pagandone la
relativa licenza. Se si sviluppa il programma con appositi Developer
e/o Tools for Application si ottiene un programma run-time che può
essere caricato su qualunque computer (coerente come S.O.) anche in
assenza di Office/Access. In queste condizioni non è necessaria alcuna
licenza.
2. Ipotizzando che sui computer target sia installato Windows XP, la
soluzione migliore sembra quella di acquisire una  licenza per "Visual
Studio Tools for Application" tramite il quale si potrà ottenere il
run-time del programma Access da distribuire.
3. Sotto l'aspetto dell'affidabilità e della sicurezza Access non è
inferiore ad altri tools. Nella  versione .mde e/o runtime (di cui non
conosco ancora le caratteristiche) è inviolabile alla pari di altri
.exe.
4. Pertanto, vista anche l'alta produttività di Access e la relativa
facilità di apprendimento e di  utilizzo (che tuttavia non ne riducono
le caratteristiche di ...... e di potenza), il vostro consiglio è di
sviluppare la parte GUI  (Graphic User Interface - maschere, query,
report, codice, ecc.) tramite Access.
5. Per quanto concerne il database, invece, il consiglio è di
abbandonare Access/Jet a favore di un SQL Server. In particolare SQL
Server Express (che tra l'altro è free) potrebbe essere la soluzione
giusta. Express ha qualche limitazione (rispetto a SQL Server
completo), ma sempre meno del Jet di Access, e comunque limitazioni
ininfluenti in un ambiente di medie dimensioni.
---------------------------------------------------------------------------------------------
Vogliate ancora verificare la correttezza di quanto segue:
- L'SQL Express devo scaricarlo dal sito Microsoft alla voce: " SQL
Server 2005 Express Edition SP2" ? Annessa c'è anche della
documentazione? O dove la si può trovare? Ovvero, per utenti esperti
di Jet/Access ci sono molte differenze o ci si può arrivare per
deduzione?
- Serve anche "SQL Server Management Studio Express" che è indicato
nello stesso sito?
- "Visual Studio Tools for Application" per Access 2003 (S.O. Windows
XP) occorre acquistarlo presso un rivenditore di software? - Inoltre
saremo in grado noi come centro di sviluppo aziendale di utilizzarlo
oppure occorre un aiuto specialistico? Il C.E.D. è formato da
programmatori AS/400 esperti che si stanno formando anche in ambiente
Access. Come detto in precedenza c'è anche una ottima conoscenza
dell'ambiente DOS e Clipper/DBaseIII.
-------------------------------------------------------------------------------------------------
Ultime curiosità:
A seguito delle mie modestissime esperienze di Visual Basic / SQL
Server, non mi suonano nuove le "stored procedures" e i "trigger".
Ma, in particolare, le incomprese "stored procedures" (con le loro
righe rosse, verdi, ecc., se non ricordo male) mi hanno sempre
spaventato. Non è mica che dovrò abbandonare le mie amate "queries" a
favore di esse? In particolare le "queries" sviluppate con tanta
facilità in Access in modalità grafica?
I "trigger" poi, che diavoleria sono?
-----------------------------------------------------------------------------------------------------
Grazie e saluti a tutti
Giorgio DANIELE - Torino


text:
Il Thu, 19 Apr 2007 17:07:12 +0200, Ludus <
lu...@tele2.it
> ha scritto:
>Con riferimento ai suggerimenti che con pazienza mi sono stati forniti
>da  MA (Massimiliano Amendola) e da VT (Vincenzo Turturro), provo a
>riepilogare quanto ho appreso, salvo ulteriori precisazioni da parte
>di MA e VT  e della comunità:
>
>1. Non è vero che sia necessario installare Office/Access su tutti i
>computer che dovranno far girare l'applicazione Access, pagandone la
>relativa licenza. Se si sviluppa il programma con appositi Developer
>e/o Tools for Application si ottiene un programma run-time che può
>essere caricato su qualunque computer (coerente come S.O.) anche in
>assenza di Office/Access. In queste condizioni non è necessaria alcuna
>licenza.
Vero.
Ove per  "coerente come S.O." si intenda "con sistema operativo compatibile con la versione runtime di Access adottata"
>2. Ipotizzando che sui computer target sia installato Windows XP, la
>soluzione migliore sembra quella di acquisire una  licenza per "Visual
>Studio Tools for Application" tramite il quale si potrà ottenere il
>run-time del programma Access da distribuire.
Chi sviluppa dovrà acquisire anche una licenza Office 2003 completa di Access.
>3. Sotto l'aspetto dell'affidabilità e della sicurezza Access non è
>inferiore ad altri tools. Nella  versione .mde e/o runtime (di cui non
>conosco ancora le caratteristiche) è inviolabile alla pari di altri
>.exe.
Vero
>4. Pertanto, vista anche l'alta produttività di Access e la relativa
>facilità di apprendimento e di  utilizzo (che tuttavia non ne riducono
>le caratteristiche di ...... e di potenza), il vostro consiglio è di
>sviluppare la parte GUI  (Graphic User Interface - maschere, query,
>report, codice, ecc.) tramite Access.
Sì
>5. Per quanto concerne il database, invece, il consiglio è di
>abbandonare Access/Jet a favore di un SQL Server. In particolare SQL
>Server Express (che tra l'altro è free) potrebbe essere la soluzione
>giusta. Express ha qualche limitazione (rispetto a SQL Server
>completo), ma sempre meno del Jet di Access, e comunque limitazioni
>ininfluenti in un ambiente di medie dimensioni.
Vero
>---------------------------------------------------------------------------------------------
>
>Vogliate ancora verificare la correttezza di quanto segue:
>
>- L'SQL Express devo scaricarlo dal sito Microsoft alla voce: " SQL
>Server 2005 Express Edition SP2" ? Annessa c'è anche della
>documentazione? O dove la si può trovare? Ovvero, per utenti esperti
>di Jet/Access ci sono molte differenze o ci si può arrivare per
>deduzione?
Lo scarichi da questo link:
http://www.microsoft.com/downloads/details.aspx?displaylang=it&FamilyID=220549b5-0b07-4448-8848-dcc397514b41
Per la documentazione e/o l'addestramento iniziale ci sono le registrazioni di alcuni webcast reperibili sul sito
Microsoft.
E poi potresti venire alla CISA a MIlano il 7/8 giugno p.v. !
http://www.accessgroup.it/index2.asp?ID=221&ID_Coll_Menu=221&Titolo=
<B>CISA%202007</b>%20(Cisa3)
dove fra l'altro è prevista anche una sessione dedicata ll'interfacciamento fra Acces e SQL Server.
>- Serve anche "SQL Server Management Studio Express" che è indicato
>nello stesso sito?
Sì
>- "Visual Studio Tools for Application" per Access 2003 (S.O. Windows
>XP) occorre acquistarlo presso un rivenditore di software?
Sì
>Inoltre saremo in grado noi come centro di sviluppo aziendale di utilizzarlo
>oppure occorre un aiuto specialistico?
Credo che non dovreste avere particolari problemi.
>Il C.E.D. è formato da programmatori AS/400 esperti che si stanno formando anche in ambiente
>Access. Come detto in precedenza c'è anche una ottima conoscenza
>dell'ambiente DOS e Clipper/DBaseIII.
Se servisse, io ho ottime conoscenze sia in ambito iSeries (AS/400) ed Access oltre che Clipper.
>-------------------------------------------------------------------------------------------------
>
>Ultime curiosità:
>
>A seguito delle mie modestissime esperienze di Visual Basic / SQL
>Server, non mi suonano nuove le "stored procedures" e i "trigger".
>
>Ma, in particolare, le incomprese "stored procedures" (con le loro
>righe rosse, verdi, ecc., se non ricordo male) mi hanno sempre
>spaventato. Non è mica che dovrò abbandonare le mie amate "queries" a
>favore di esse? In particolare le "queries" sviluppate con tanta
>facilità in Access in modalità grafica?
No, però una stored procedure ha il vantaggio di "girare" sul server invece che in locale, per cui i dati che viaggiano
sulla rete sono solo quelli restituiti dall'istruzione SQL.
Quindi fai tu le debite considerazioni riguardo alle prestazioni di una query Access rispetto ad una stored procedure.
>I "trigger" poi, che diavoleria sono?
Un trigger è una funzione, scritta in un particolare linguaggio proprietario del DBMS, la cui esecuzione viene associata
al verificarsi di particolari eventi su determinate tabelle.
Per esempio puoi definire un trigger che al verificarsi della cancellazione di un record da una certa tabella salva il
record in una tabella di backup in modo da mantenere una copia.
E' ovvio il vantaggio dei trigger: chiunque, uomo o programma, esegua un'operazione su una tabella di un db, il trigger
esegue le azioni stabilite.
In questo modo puoi implementare tutta una serie di funzioni a livello del db e non a livello applicativo, con gli ovvi
vantaggi di manutenibilità.
>
>-----------------------------------------------------------------------------------------------------
>
>Grazie e saluti a tutti
>
>Giorgio DANIELE - Torino
>
>



text:
Il Thu, 19 Apr 2007 17:07:12 +0200, Ludus <
lu...@tele2.it
> ha scritto:
>(.....)
I webcast su SQL Server Express a questo link (li trovi in fondo alla pagina):
http://www.microsoft.com/italy/msdn/risorsemsdn/sql/percorso.mspx



text:
On Thu, 19 Apr 2007 21:15:10 +0200, "VT @ home" <
V...@home.it
> wrote:
.
... OMISSIS ...
>
>Se servisse, io ho ottime conoscenze sia in ambito iSeries (AS/400) ed Access oltre che Clipper.
>

A Torino?



author: VT @ Work

text:
On Thu, 19 Apr 2007 22:35:27 +0200, Ludus <
lu...@tele2.it
> wrote:
>On Thu, 19 Apr 2007 21:15:10 +0200, "VT @ home" <
V...@home.it
> wrote:
>.
>... OMISSIS ...
>>
>>Se servisse, io ho ottime conoscenze sia in ambito iSeries (AS/400) ed Access oltre che Clipper.
>>
>
>A Torino?
Io vivo e lavoro in provincia di Firenze, ma con gli strumenti di oggi
non credo che la distanza sia un problema.



text:
On Fri, 20 Apr 2007 06:17:12 GMT, V...@Work.it (VT @ Work) wrote:
>>On Thu, 19 Apr 2007 21:15:10 +0200, "VT @ home" <
V...@home.it
> wrote:
>Io vivo e lavoro in provincia di Firenze, ma con gli strumenti di oggi
>non credo che la distanza sia un problema.
>>>Vincenzo Turturro
Puoi fornirmi un indirizzo telefonico per sentirci in orario di
ufficio? Così puoi parlare anche con il Capo Centro dell'azienda.
Come indirizzi e-mail posso usare V...@Work.it e
V...@home.it
  ?
Appena posso aprirò un altro thread sull'argomento Access / Run-time /
SQL Server Express, con i primi risultati ottenuti a seguito dei
vostri suggerimenti.
Giorgio DANIELE - Torino



text:
Il Mon, 23 Apr 2007 09:36:14 +0200, Ludus <
lu...@tele2.it
> ha scritto:
>On Fri, 20 Apr 2007 06:17:12 GMT, V...@Work.it (VT @ Work) wrote:
>
>>>On Thu, 19 Apr 2007 21:15:10 +0200, "VT @ home" <
V...@home.it
> wrote:
>
>>Io vivo e lavoro in provincia di Firenze, ma con gli strumenti di oggi
>>non credo che la distanza sia un problema.
>
>>>>Vincenzo Turturro
>
>Puoi fornirmi un indirizzo telefonico per sentirci in orario di
>ufficio? Così puoi parlare anche con il Capo Centro dell'azienda.
Manda un messaggio e-mail a questo indirizzo:
v punto turturro chiocciola tiscali punto it
ed io ti risponderò fornendoti il mio numero di telefono.
Sai com'è ... si tratta del cellulare e non intendo renderlo pubblico.



title: caricamento dati da un excel a tre tabelle

text:
buongiorno a tutti.
volevo un consiglio su come predisporre un db e in particolare qualche "dritta" su come caricarne i dati.
Mi spiego meglio.
Mi pervengono diversi excel ciascuno dei quali è così composto :

1 - ufficio
2 - codice ufficio
3 - indirizzo ufficio

1/a - codice contatore luce
a1 - data lettura contatore luce
a2 - valore lettura contatore luce

1/b - codice contatore gas
b1 - data lettura contatore gas
b2 - valore lettura contatore gas

1/c - codice contatore acqua
c1 - data lettura contatore acqua
c2 - valore lettura contatore acqua

Preciso che i campi 1/a ; 1/b ; 1/c  sarebbero superflui ma, per il momento mi servono per verificare di non fare cavolate.

Avrei bisogno, e questo è il mio dilemma di una query, (e preciso solo una e non tre, non so se è possibile) che leggendo solo i record compilati nel campo data mi crei (o aggiunga i dati a) tre tabelle così composte:

tabella luce
2 - codice ufficio
1/a - codice contatore luce
a1 - data lettura contatore luce
a2 - valore lettura contatore luce

tabella gas
2 - codice ufficio
1/b - codice contatore gas
b1 - data lettura contatore gas
b2 - valore lettura contatore gas

tabella acqua
2 - codice ufficio
1/c - codice contatore acqua
c1 - data lettura contatore acqua
c2 - valore lettura contatore acqua

So che a molti sembrerà una richiesta futile, ma vi chiedo un cortese e utilissimo aiuto, vorrei eseguire il minor numero di lavorazioni possibile, evitando soprattutto di farlo in excel.
grazie.


text:
mi scuso se insisto ma non riesco a venirne fuori.
Sono riuscito a fare una query di accodamento dati a tabella ma vorrei "espandere" la stessa in modo tale da poter, con una sola query, alimentare le tre tabelle che mi servono.
Secondo voi è possibile e qualcuno mi può aiutare ?
grazie


text:
Allego il codice nella speranza di trovare un'anima buona...

INSERT INTO tbl_DATIENE ( CodImmobile, Data1, [Energia attiva Fascia 1], [Energia attiva Fascia 2], [Energia attiva Fascia 3] )
SELECT PROVACARICAMENTO.CodImmobile, PROVACARICAMENTO.Data1, PROVACARICAMENTO.[Energia attiva Fascia 1], PROVACARICAMENTO.[Energia attiva Fascia 2], PROVACARICAMENTO.[Energia attiva Fascia 3]
FROM PROVACARICAMENTO;

devo valorizzare altre due tabelle "DATIGAS" E "DATIH20" con altri record sempre  provenienti dalla tabella PROVACARICAMENTO.
grazie infinite a chiunque mi potrà aiutare....


text:

Perchè una sola query?


text:
Perché nella mia ignoranza pensavo si potesse fare....
Poi vedendo che nessuno mi rispondeva ho fatto tre query distinte che, se non ho capito male, posso avviare con un unica macro.
Ciao grazie mille.


title: Re: stesso report per più maschere

author: Karl Donaubauer

text:
Salve,

Alberto Luzi:
> apro lo stesso report da diverse maschere,
> perchè il report è lo stesso;
> cambia solo la Where...
> Ho impostato la query su apertura di ogni maschera in questione:
>      strSql = "SELECT * FROM Elenco" _
>        & " WHERE Tipo = 'Primo';"
>      DBEngine(0)(0).QueryDefs("QryMioElenco").Sql = strSql
> ma credo si meglio su click del pulsante che apre il report

Se cambia solo la parte WHERE, allora non dovresti riscrivere la query
ogni volta, ma semplicemente usare l'argomento WHERE di OpenReport:

DoCmd.OpenReport "MioBelloReport", acViewPreview, , "Tipo = 'Primo'"
poi
DoCmd.OpenReport "MioBelloReport", acViewPreview, , "Tipo = 'Secondo'"
ecc.

--
Ciao
Karl
*********
http://AccessDevCon.com

Access FAQ:
https://www.donkarl.com/it


title: Re: stesso report per più maschere

author: Alberto Luzi

text:

grazie


title: Re: stesso report per più maschere

text:

e nel caso di sottoreport che cambia solo where,
questo non si può fare?


title: Re: stesso report per più maschere

text:
Salve,

Alberto Luzi:
>> Karl Donaubauer ha scritto:
>>> Alberto Luzi:
>>>> apro lo stesso report da diverse maschere,
>>>> perchè il report è lo stesso;
>>>> cambia solo la Where...
>>>> Ho impostato la query su apertura di ogni maschera in questione:
>>>> strSql = "SELECT * FROM Elenco" _
>>>> & " WHERE Tipo = 'Primo';"
>>>> DBEngine(0)(0).QueryDefs("QryMioElenco").Sql = strSql
>>>> ma credo si meglio su click del pulsante che apre il report
>>>
>>> Se cambia solo la parte WHERE, allora non dovresti riscrivere la query
>>> ogni volta, ma semplicemente usare l'argomento WHERE di OpenReport:
>>>
>>> DoCmd.OpenReport "MioBelloReport", acViewPreview, , "Tipo = 'Primo'"
>>> poi
>>> DoCmd.OpenReport "MioBelloReport", acViewPreview, , "Tipo = 'Secondo'"
>>> ecc.
>>> ...
> e nel caso di sottoreport che cambia solo where,
> questo non si può fare?

No. Per i sottoreport è abbastanza comune di riscrivere l'SQL della query.



title: Re: stesso report per più maschere

text:

ancora grazie


title: protocollo documenti

author: KKKXXX

text:
Ho un db che per intenderci svolge il ruolo di protocollo generale dei
documenti è strutturato  in questo modo:
tabelle:
documenti- con campi Iddocumenti, idclienti prot, eldoc, collocazione ecc.
il campo ( casella combinata) eldoc ha una origine riga in una query la
quale elenca alfabeticamente tutte le tipologie  di documenti. Il campo
collocazione ( casella combinata) ha origine nella tabella collocazione ove
ci sono elencati tutte le possibili collocazioni.
le altre tabelle:
collocazione - v.sopra
eldoc - c'e' l'elenco di tutti i documenti
clienti - l'anagrafica di tutte i clienti
query:
1° query - v. sopra
2° query - serve a collegare i documenti a ciascun impresa
forms:
un solo form, in cui vi è l'anagrafica dell'impresa ed una sottomaschera in
cui vengono inseriti i documenti, il prot è inserito manualmente la
tipologia del documento con una casella combinata e la collocazione pure,
gli altri campi sono la data e altro che sono praticamente sempre uguali.
Eccoci alla domanda: come faccio a fare in modo che una volta selezionato un
certo tipo di documento nel campo eldoc mi dia in automatico la giusta
collocazione? dandomi cmq la possibilità di inserire manulamente un'altra
collocazione se non corretta.
Immagino che non sia stato chiarissimo eventualmente tempestatemi di domande
;-)
grazie


title: Form.[tipo origine riga] = <Funzione> 'come impostarla? [q11c1]

author: Sergio Villa

text:
In un'applicazione Access 97 sr-2 ho previsto form video con
numerosi campi di tipo "casella combinata" che visualizzano voci dizionario,
con:
[Tipo Origine riga] = "tabella/query"
[Origine
riga]         = <il nome della query
che ottiene le voci dizionario>
Siccome le voci dizionario sono numerose,
devo preparare per ciascun dizionario una query specifica,
dove SQL ="Select
distinctrow CVOCE, CDESC from TDIZI where CTIPO = 'dbUM' order by CVOCE;"
Si
attua quindi una Proliferazione di queries, distinte soltanto dal valore di
selezione di CTIPO.
Ora, siccome si può mettere in "Tipo Origine riga" una
funzione con parametri, vorrei impostare con una singola funzione che ha come
parametro il tipo dizionario e con questo rigenera di volta in volta
l'istruzione SQL della Query. P.e.:

function tipo_orig_riga(x_para as string) as string

Set MyQdef = MyDaba.QueryDefs("qyDIZI")
  MyQdef.sql = "Select
distinctrow CVOCE, CDESC from TDIZI where CTIPO = " + X_para + "'"

Tipo_orig_riga = "qyDIZI"
End function

Nell'Help in linea si precisa FUNZ( controllo as control, id
as variant, riga as variant, colonna as variant, codice as variant),
ma pur
seguendolo, non parte. La domanda:
Come si usa
correttamente una funzione in "Tipo Origine Riga"?
Oppure, più in generale, potete darmi uno spunto per la risoluzione del
problema specificato?
Vi ringrazio per l'attenzione e per gli spunti che
sarete in grado di fornirmi

Sergio


author: Nicola Ardito

text:
Le funzioni origine di listbox o combobox funzionano anche se
non è semplicissimo scriverle (almeno per me).

Se posti la funzione possiamo cercare di capire perchè
non va.

Ciao Nicola



title: Complimenti e domanda

author: Maurizio Borrelli

text:
A ciascuno il suo e onore al merito. ;-)
--
Ciao :o)
Maurizio
--------
?SPQR(C)
 X
--------
************************************************************
From: "Guido" <
giroatlNO...@tin.it
>
Newsgroups: microsoft.public.it.office.access
Subject: Complimenti e domanda
Lines: 24
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-ID: <YOnrb.440602$
R32.14...@news2.tin.it
>
Date: Sun, 09 Nov 2003 09:30:32 GMT
NNTP-Posting-Host: 80.180.90.52
X-Complaints-To:
newsm...@tin.it
X-Trace:
news2.tin.it
 1068370232 80.180.90.52 (Sun, 09 Nov 2003 10:30:32
MET)
NNTP-Posting-Date: Sun, 09 Nov 2003 10:30:32 MET
Organization: TIN
Path:
TK2MSFTNGP08.phx.gbl!
newsfeed00.sul.t-online.de
!
t-online.de
!tiscali!newsfeed
1.ip.tiscali.net
!
news-out.tin.it
!
news-in.tin.it
!news2.tin.it.POSTED!not-for-
mail
Xref: TK2MSFTNGP08.phx.gbl microsoft.public.it.office.access:7365
per cominciare complimenti al Sito Comune; fatto bene, risposte chiare.
molto VBA, ma occasione utile per impararlo (meglio di quel poco che già
so).
Domanda:
cotruito un report per la visualizzazione di una query, ho costruito pure
una form con un pulsante che mi presenta "in anteprima di stampa" il report.
Solo che...lo zoom che posso decidere (a priori) è limitato a poche
scelte...non posso scegliere uno zoom dell'83%.
O almeno a codice non ci sono riuscito...
Qualcuno mi aiuta?
Grazie
Guido
--
in moto:
sfortunà tanti
fortunà pochi
bravi gnanca uno
************************************************************


title: campo testo - contatore a condizione 2

author: luigi onofrio

text:
riassumo cosa mi serve:
avendo in una tabella "TABELLA2" un campo "SI_NO" i cui valori possono
essere a scelta SI o NO, devo in un altro campo "NUMERO" di tipo testo
avere in automatico una numerazione incrementale sia per i valori SI che
per i NO del campo "SI_NO"
e quindi nel campo "numero" possono esserci 1,1,2,2,3,3,ecc e non devono
esserci più di due numeri uguali.
in un precedentre tread, Potone mi ha consigliato di inserire
nell'intestazione di una maschera "TABELLA1" un controllo non associato di
nome "Scelta_SI_NO" nel cui valore predefinito inserire la seguente
formula:
IIf(DCount("[numero]","tabella1","si_NO="
&[Scelta_si_NO])=0,"0000001",Format$(DMax("[numero]","tabella1","si_NO="
&[Scelta_si_NO])+1,"0000000"))
dopo averla provata, non mi funziona dandomi errore di sintassi.
Siccome io con la sintassi ho poca dimestichezza, chiedo un ulteriore
aiuto per risolvere questo mio rompicapo.
grazie.
e auguri posticipati
--
questo articolo e` stato inviato via web dal servizio gratuito
http://www.newsland.it/news
 segnala gli abusi ad
ab...@newsland.it


title: campo testo - contatore a condizione 2

author: Roberto da casa

text:
"luigi onofrio" <
onofrio...@tin.it
> ha scritto nel messaggio
news:dor0k8$e26$1...@news.newsland.it...
> riassumo cosa mi serve:
> avendo in una tabella "TABELLA2" un campo "SI_NO" i cui valori possono
> essere a scelta SI o NO, devo in un altro campo "NUMERO" di tipo testo
> avere in automatico una numerazione incrementale sia per i valori SI che
> per i NO del campo "SI_NO"
> e quindi nel campo "numero" possono esserci 1,1,2,2,3,3,ecc e non devono
> esserci più di due numeri uguali.
> in un precedentre tread, Potone mi ha consigliato di inserire
> nell'intestazione di una maschera "TABELLA1" un controllo non associato di
> nome "Scelta_SI_NO" nel cui valore predefinito inserire la seguente
> formula:
> IIf(DCount("[numero]","tabella1","si_NO="
> &[Scelta_si_NO])=0,"0000001",Format$(DMax("[numero]","tabella1","si_NO="
> &[Scelta_si_NO])+1,"0000000"))
> dopo averla provata, non mi funziona dandomi errore di sintassi.
Se lo hai scritto vella proprietà Valore predefinito di una casella di testo
devi far precedere il tutto dal segno = e sostituire le virgole con dei
punti e virgola: questo per quanti riguarda le regole di sintassi.
Però una cosa del scritta nel Valore predefinito è un non senso: il valore
predefinito viene calcolato quando viene presentato VUOTO un nuovo record da
inserire: ma se il record è ancora vuoto anche il campo di tipo Si/no non è
stato ancora impostato, quindi non ha senso condizionare al suo valore
l'algoritmo per determinare il valore del numero progressivo; insomma una
cosa del genere scritta nel valore predefinito di una caella di testo può
funzionare solo se non contiene condizionamenti da valori di campi che non
sono stati ancora definiti.
> Siccome io con la sintassi ho poca dimestichezza, chiedo un ulteriore
> aiuto per risolvere questo mio rompicapo.
> grazie.
> e auguri posticipati
Anche a te.
--
Roberto
-----------------------------------------------
il Sito Comune di it.comp.appl.access
http://www.sitocomune.com
-----------------------------------------------


title: campo testo - contatore a condizione 2

text:
Roberto da casa ha scritto:



> Anche a te.
e secondo te, come me la sbrigo????
la formula si può usare o si deve cambiare?



title: campo testo - contatore a condizione 2

text:
"luigi onofrio" <
onofrio...@tin.it
> ha scritto nel messaggio
news:doron2$j6s$1...@news.newsland.it...

Invece che scrivere l'algoritmo nella proprietà Valore predefinito di una
casella di testo, calcolati il valore di tale casella di testo 8quindi dal
campo ad essa associato, a fronte dell'evento "Prima di aggiornare" della
maschera.
Per il calcolo puoi usare una formula simile a quella anche se forse invece
di una funzione IIf, visto che usi VBA, è meglio una If ... Else ... End If.
> la formula si può usare o si deve cambiare?
Il problema non è cambiare la formula, ma è dove scriverla.
Comunque devi togliermi una curiosità: se dopo che hai assegnato il valore
al campo [numero] qualcuno cambia il valore del campo si_NO cosa succede?



title: campo testo - contatore a condizione 2

text:






devo fare in modo che il campo SI_NO venga bloccato dopo il salvataggio
del record (magari facendo un doppio passaggio,lanciando un messaggio di
avvertimento se si è sicuri del salvataggio) e il numero non modificabile
dopo il salvataggio.
Ma qua la cosa per me si fa impossibile, devo solo sperare nella grazia di
...... :-==))
che ne dici?



title: campo testo - contatore a condizione 2

text:
luigi onofrio ha scritto:







> ....... :-==))
> che ne dici?
pensando ancora all'argomento, siccome è un applicativo nuovo, posso anche
sostituire il campo SI_NO in altro formato tipo testo o numerico e usare
dei pulsanti di comando per il si o il no. Insomma potrei gestire la cosa
nel modo migliore.



title: campo testo - contatore a condizione 2

text:
"luigi onofrio" <
onofrio...@tin.it
> ha scritto nel messaggio
news:dort6a$uno$1...@news.newsland.it...

Decidi tu come impostare i termini del problema, poi magari insieme viediamo
le soluzioni, se dovessi avere difficoltà a trovarle da solo.



title: campo testo - contatore a condizione 2

text:
 > riassumo cosa mi serve:
> avendo in una tabella "TABELLA2" un campo "SI_NO" i cui valori
 > possono
 > essere a scelta SI o NO, devo in un altro campo "NUMERO" di tipo
> > testo
> avere in automatico una numerazione incrementale sia per i
> valori SI
 > che
> per i NO del campo "SI_NO"
 > e quindi nel campo "numero" possono esserci 1,1,2,2,3,3,ecc e
> non
 > devono
> esserci più di due numeri uguali.
cut
 > invece
 > di una funzione IIf, visto che usi VBA, è meglio una If ... Else ...
> End If.
> >
> > > > > la formula si può usare o si deve cambiare?
> >
> > > > Il problema non è cambiare la formula, ma è dove scriverla.
> >
> > > > Comunque devi togliermi una curiosità: se dopo che hai assegnato il
> valore
> > > > al campo [numero] qualcuno cambia il valore del campo si_NO cosa
> succede?
> >
> > > devo fare in modo che il campo SI_NO venga bloccato dopo il salvataggio
> > > del record (magari facendo un doppio passaggio,lanciando un messaggio di
> > > avvertimento se si è sicuri del salvataggio) e il numero non
> modificabile
> > > dopo il salvataggio.
> > > Ma qua la cosa per me si fa impossibile, devo solo sperare nella grazia
> di
> > > ....... :-==))
> > > che ne dici?
> > pensando ancora all'argomento, siccome è un applicativo nuovo, posso anche
> > sostituire il campo SI_NO in altro formato tipo testo o numerico e usare
> > dei pulsanti di comando per il si o il no. Insomma potrei gestire la cosa
> > nel modo migliore.
> Decidi tu come impostare i termini del problema, poi magari insieme viediamo
> le soluzioni, se dovessi avere difficoltà a trovarle da solo.
io Avrei pensato:
impostare il campo SI_NO a numerico con valori predefiniti vuoto(default),
0 (NO),1 (SI), non modificabili direttamente .
fare su una maschera due pulsanti di comando di cui uno assegni il numero
0  al campo SI_NO e incrementare il numero contatore  al campo "NUMERO" ai
valori 0 del campo SI_NO se questo campo è vuoto, l'altro assegna il
numero 1  al campo SI_NO e incrementare un numero di contatore ai valori 1
del campo SI_NO sempre se questo è vuoto. Tutti e due non devono
funzionare se il valore del campo SI_NO è assegnato, cioè vi sia 1 o
0,(quindi disabilitati per le modifiche).
il Campo "NUMERO" non deve avere più di 2 valori uguali).
A questo punto non capisco più niente! come proseguire?
penso, evento su clik dei singoli pulsanti inserire:
if non so, then non so, else non so
sono completamente bloccato.
SOS
spero di avermi fatto capire!



title: BE sul server, quali accorgimenti?

author: Filippo

text:
Buongiorno, confesso di non conoscere i problemi relativi ad una
gestione data base in rete.
Premesso che si tratta di solo cinque client e un server, ho un FE su
ogni client e il BE con le sole tabelle sul server.
Le tabelle sono collegate dai singoli files MDB presenti su ogni
client.
Io mi sono limitato a questo e tutto sommato funziona, però NON SO se
occorrono altri accorgimenti (non so, priorità, record blocati,
semafori, flussi e tutte quelle cose relative alle  reti che ignoro).
In realtà a me pare che se vi sono due utenti che contemporaneamente
operano sul data base, anche se su due record diversi, il sistema
rallenta enormemente e a volte si blocca.
E' evidente che manca qualcosa, ma che?
Non so se sono stato abbastanza chiaro.
Magari datemi qualche indicazione anche di tipo bibliografico (siti,
files, forum etc) in modo che possa studiare da solo senza rompere le
scatole.
Grazie
Filippo


title: BE sul server, quali accorgimenti?

author: Sergio MAZZA

text:
"Filippo" <
f....@panservice.it
> ha scritto nel messaggio
news:u04394h0eskbjvg3s...@4ax.com...

Prova iniziando da qui:
Come ottimizzare la prestazione di rete di motore di database Office Access
e Jet con i client basati su Windows 2000 e basati su Windows XP
http://support.microsoft.com/kb/889588
www.sitocomune.com
 - Sezione General
6.135 Caratteristiche generali di esecuzione e tecniche di ottimizzazione di
Microsoft Jet 3.5
Ciao.
--
Sergio MAZZA


title: Blocco Sistema

text:
Quando tento di aprire un file da Risorse del Computer, ovvero se avvio IE,
o winfax ecc, il computer mi va in blocco ( in particolare MsMgr, msgmsv32,
ecc) da che dipende ? cosa dovrei fare ?
Scusate se non c'entra niente con Access.


title: Blocco Sistema

text:

Ad un mio amico che usa molto il pc sono uscite delle verrucche, conosci un
buon prodotto???
ciao MAssimiliano
--------------------------------
Inviato via
http://usenet.libero.it


title: Blocco Sistema

author: Cristiano Zanni

text:
"MA"
> Ad un mio amico che usa molto il pc sono uscite delle verrucche, conosci
un
> buon prodotto???
L'amico tuo è A. Cara?


title: Blocco Sistema

author: Mar&mar

text:
"Gippo71" <
gip...@hotmail.com
> ha scritto nel messaggio
news:Oshca.55622$pG1.1...@news1.tin.it...

prova a postare su  "it.comp.os.win.(tuo sistema operativo)" visto che oltre
OT , non hai neanche specificato il S.O.
--
-----------------------------------------------------------
Mar&mar
-----------------------------------------------------------
il Sito Comune di it.comp.appl.access:
http://www.sitocomune.com
-----------------------------------------------------------


title: Invio fax con MAPI e VBA

author: Eugenio

text:
SBS2003 - Exchange2003 - MAPI - Outlook2003 - VBA - Access97
Ho un problema ad inviare fax attraverso un'applicazione da me realizzata in
Access97 (VBA).
Per inoltrare fax o mail utilizzo MAPI, per le e-mail non ci sono problemi,
mentre per il fax ricevo il seguente errore
---------------------------------------
'numeroditelefono' 30/11/06 17.29
Impossibile recapitare il messaggio. Sistema di posta elettronica del
destinatario sconosciuto o non valido. Controllare l'indirizzo e riprovare
oppure contattare l'amministratore di sistema per verificare la connettività
con il sistema di posta elettronica del destinatario.
<
dominio.it
 #5.1.2>
---------------------------------------
Ho provato ad inviare un fax direttamente da outlook2003 specificando nel
campo indirizzo [fax:numeroditelefono] e in effetti la mail viene inviata.
Passando allo stesso modo il numero di fax nella mia applicazione invece no.
Però se verifico in outlook il messaggio sembra stato inviato e la
visualizzazione del numero di fax nel campo A è identitica sia su i messaggi
generati automaticamente che su i messaggi inviati manualmente da outlook.
Spero di essermi spiegato.
Qualcuno ha suggerimenti?
Grazie
Ciao
Eugenio


title: Invio fax con MAPI e VBA

text:
"Eugenio" <
epiw...@tiscali.it
> ha scritto nel messaggio
news:456feb25$0$7750$5fc...@news.tiscali.it...

Leggendo l'esempio su MS (
http://support.microsoft.com/kb/301109/en-us
) noto
che c'è uno spazio tra fax: e il numero da comporre; hai già provato?
Ciao.
--
Sergio MAZZA


title: Invio fax con MAPI e VBA

text:

Si ho provato entrambi i casi.
Il link fa riferimento a SBS4.5 (oltre che SBS2000), il sistema operativo
del server in funzione ai tempi dello sviluppo dell'applicazione, ed in
effetti ai tempi funzionava.
Poi, due anni fa, il server è stato cambiato (SBS2003) e il fax, che veniva
usato raramente nell'applicazione, evidentemente non è più stato usato.
Purtroppo dopo due anni è "necessario" usare di nuovo il fax.
Magari, una volta risolto il problema, per altri due anni non si userà più
il fax ( :-)))))))  ), ma l'applicazione lo prevede e vorrei che tornasse a
funzionare :-( .
Per la verità è cambiato anche il client di posta, da Outlook 98 a 2003, e
quando invio il fax, in corrispondenza dell'esecuzione della funzione
MAPISendMail, mi viena emessa una box nella quale c'è scritto:
"Un programma sta tentando di inviare automaticamente la posta elettronica.
Consentire l'operazione?
Se l'operazione non è prevista, potrebbe trattarsi di un virus, pertanto
scegliere "No". "
Questa segnalazione viene emessa solo nel caso di invio fax, mentre tutto è
regolare nell'invio delle e-mail.
Grazie.
Ciao


title: Invio fax con MAPI e VBA

text:
"Eugenio" <
epiw...@tiscali.it
> ha scritto nel messaggio
news:457005fb$0$7749$5fc...@news.tiscali.it...
> Si ho provato entrambi i casi.
>
> Il link fa riferimento a SBS4.5 (oltre che SBS2000), il sistema operativo
> del server in funzione ai tempi dello sviluppo dell'applicazione, ed in
> effetti ai tempi funzionava.
> Poi, due anni fa, il server è stato cambiato (SBS2003) e il fax, che
> veniva usato raramente nell'applicazione, evidentemente non è più stato
> usato.
> Purtroppo dopo due anni è "necessario" usare di nuovo il fax.
> Magari, una volta risolto il problema, per altri due anni non si userà più
> il fax ( :-)))))))  ), ma l'applicazione lo prevede e vorrei che tornasse
> a funzionare :-( .
>
>
> Per la verità è cambiato anche il client di posta, da Outlook 98 a 2003, e
> quando invio il fax, in corrispondenza dell'esecuzione della funzione
> MAPISendMail, mi viena emessa una box nella quale c'è scritto:
>
> "Un programma sta tentando di inviare automaticamente la posta
> elettronica.
> Consentire l'operazione?
>
> Se l'operazione non è prevista, potrebbe trattarsi di un virus, pertanto
> scegliere "No". "
>
> Questa segnalazione viene emessa solo nel caso di invio fax, mentre tutto
> è regolare nell'invio delle e-mail.
>
> Grazie.
> Ciao
E' possibile che il livello di protezione si troppo alto o l'antivirus è
troppo invadente...
Ciao.
--
Sergio MAZZA


title: File formato QIF

author: Andrea Montanari

text:
Buon giorno,
qualcuno sa dirmi se è possibile esportare con Access 2000 dati in formato
QIF ??
Esiste qualche link ove è spiegato, anche per mezzo di ulteriori passaggi
e/o convertitori come è possibile farlo ??
Grazie a tutti per l'interessamento !
AM


title: File formato QIF

text:

Ciao tu sei il padre del dbaManager?
Bel prodotto, complimenti
Ma il qif file è un file come csv, qual'è il problema?
--
_ _
Ciao
MAssimiliano Amendola
www.accessgroup.it
Cisa - Conferenza Italiana per Sviluppatori Access
Info:
www.donkarl.com/it


title: File formato QIF

text:
Premetto, a scanso di equivoci, che non sono il "padre del dbaManager", ma
semplicemente un appassionato di access che si diverte a "smanettare" con
questo ottimo strumento !
Ritornando al mio problema ...
Ho in una tabella registrato dei pagamenti che vengono effettuati con CC
postale da clienti.
Vorrei esportare giornalmente questi record in un file QIF per poter
successivamente importare tale file in Microsoft Money, che come noto
utilizza tale formato di interscambio.
Probabilmente mi sto annegando nel classico bicchier d'acqua ..., e pertanto
gradirei qualche consiglio per poter prendere la strada giusta senza perdere
tempo ...
Grazie ancora.
/AM
"MA" <
mas...@massimilianoamendola.it
> ha scritto nel messaggio
news:dsvfaq$do4$1...@area.cu.mi.it...



title: riferimenti dll ocx per i moduli

author: marcello

text:
il mio mdb ha come riferimenti del codice i seguenti componenti:
COMCTL32.OCX
dao350.dll
MSCAL.OCX
mscomct2.ocx
MSWINSCK.OCX
Richtx32.ocx
SNAPVIEW.OCX
MSACC8.OLB
VBA332.DLL
per evitare differenti percorsi tra pc che hanno xp e w98 ho posizionato una
copia di tutti i file in una directory e li ho registrati con REGSVR32.EXE.
per alcuni file non riesco a modificare il percorso memorizzato nell'mdb (da
strumenti - riferimenti - sfoglia) nella struttura moduli, in
particolare per:
VBA332.DLL
MSACC8.OLB
mi compare un messaggio di errore legato al fatto che i due file sono
utilizzati e non č possibile modificare il percorso.
Apro l'mdb con lo shift premuto, quindi penso che non debba partire nessun
codice.
Che soluzione ho?
Grazie


title: Creazione automatica file

text:
 Vorrei sapere in quale modo si può far esportare dei report in modo
automatico ad access...
Grazie,
 Mauro
--
- - - - - - - - -
Il mondo si divide in 10 tipi di persone: quelle che capiscono il codice
binario e quelle che non lo capiscono
- - - - - - - - -
Visitate
www.insecta.it


title: Creazione automatica file

author: MA

text:
Il 05 Mar 2003, 14:52, "\(¯`·.¸Insecta¸.·´¯\)" <opet...@NOSPAMhotmail.com>
ha scritto:
> Vorrei sapere in quale modo si può far esportare dei report in modo
> automatico ad access...
> Grazie,
> Mauro
Spiegati meglio: tu vuoi esportare da Access in qualcosa o importare in
Access da qualcosa. In entrambi i casi ciò che hai scritto non è chiaro.
ciao MAssimiliano
--------------------------------
Inviato via
http://usenet.libero.it


title: Creazione automatica file

author: Xymox

text:
"(¯`·.¸Insecta¸.·´¯)" <opet...@NOSPAMhotmail.com> ha scritto
> Vorrei sapere in quale modo si può far esportare dei report in modo
> automatico ad access...
> Grazie,
>  Mauro
Spedisce a Word il tuo report:
DoCmd.OutputTo acOutputReport, "nome report", acFormatRTF, "Offerta.rtf",
True
--
ciao MarcoS
www.marcosanti.it
---------------------------------------------------
Non smetteremo di esplorare
E alla fine di tutto il nostro andare
Ritorneremo al punto di partenza
Per conoscerlo per la prima volta
T.S.Eliot
---------------------------------------------------


title: Creazione automatica file

text:
MA <
massimilia...@kksrl.com
> wrote:
> Il 05 Mar 2003, 14:52, "\(¯`·.¸Insecta¸.·´¯\)"
> <opet...@NOSPAMhotmail.com> ha scritto:
>> Vorrei sapere in quale modo si può far esportare dei report in modo
>> automatico ad access...
>> Grazie,
>> Mauro
>
> Spiegati meglio: tu vuoi esportare da Access in qualcosa o importare
> in Access da qualcosa. In entrambi i casi ciò che hai scritto non è
> chiaro. ciao MAssimiliano
Vorrei esportare direttamente un report creato da access in word... Come si
può fare?
Grazie,
 Mauro
 --------------------------------
> Inviato via
http://usenet.libero.it
--



title: Creazione automatica file

text:
Xymox <
marco.santi...@libero.it
> wrote:
> "(¯`·.¸Insecta¸.·´¯)" <opet...@NOSPAMhotmail.com> ha scritto
>
>> Vorrei sapere in quale modo si può far esportare dei report in modo
>> automatico ad access...
>> Grazie,
>>  Mauro
>
> Spedisce a Word il tuo report:
> DoCmd.OutputTo acOutputReport, "nome report", acFormatRTF,
> "Offerta.rtf", True
Dove va inserito il comando?



title: Creazione automatica file

text:
"(¯`·.¸Insecta¸.·´¯)" <opet...@NOSPAMhotmail.com> ha scritto
> > Spedisce a Word il tuo report:
> > DoCmd.OutputTo acOutputReport, "nome report", acFormatRTF,
> > "Offerta.rtf", True
>
> Dove va inserito il comando?
> Grazie,
>  Mauro
Su un qualsiasi pulsante di una form, l'importante è che a quel punto il
Report abbia i dati che vuole.



title: Creazione automatica file

text:
Xymox <
marco.santi...@libero.it
> wrote:
> "(¯`·.¸Insecta¸.·´¯)" <opet...@NOSPAMhotmail.com> ha scritto
>
>>> Spedisce a Word il tuo report:
>>> DoCmd.OutputTo acOutputReport, "nome report", acFormatRTF,
>>> "Offerta.rtf", True
>>
>> Dove va inserito il comando?
>> Grazie,
>>  Mauro
>
> Su un qualsiasi pulsante di una form, l'importante è che a quel punto
> il Report abbia i dati che vuole.
Ok, grazie, funziona benissimo...
Sarebbe possibile aggiungere al nome la data del giorno tipo
listino_10-03-2003 ?
Le altre cose che poi vorrei automatizzare sarebbero:
modificare l'interlinea del file generato da singola a esatta dimensione 9
Salvare il file in formato doc
Inviarlo in allegato in una e-mail singola con oggetto e destinatario fisso
e con il corpo del testo contenente del testo che gli fornisco io
Possibile o troppo complicato?
Grazie,
 Mauro



title: Creazione automatica file

text:
"(¯`·.¸Insecta¸.·´¯)" <opet...@NOSPAMhotmail.com> ha scritto >
> Ok, grazie, funziona benissimo...
> Sarebbe possibile aggiungere al nome la data del giorno tipo
> listino_10-03-2003 ?
> Le altre cose che poi vorrei automatizzare sarebbero:
> modificare l'interlinea del file generato da singola a esatta dimensione 9
> Salvare il file in formato doc
con il metodo DoCmd.OutputTo non credo sia possibile, ma spero che qualcuno
mi smentisca :-)



title: Creazione automatica file

author: Emyr

text:
On Thu, 6 Mar 2003 12:35:19 +0100, "Xymox"
<
marco.santi...@libero.it
> wrote:
>con il metodo DoCmd.OutputTo non credo sia possibile, ma spero che qualcuno
>mi smentisca :-)
si che puoi basta dire che il nome dl file da ottenere sia
"listino_" & format(date(),"dd/mm/yy")
Saluti.
Emanuele.


title: Creazione automatica file

text:
"Emyr" <
fan...@tiscali.it
> ha scritto
> >con il metodo DoCmd.OutputTo non credo sia possibile, ma spero che
qualcuno
> >mi smentisca :-)
>
> si che puoi basta dire che il nome dl file da ottenere sia
> "listino_" & format(date(),"dd/mm/yy")
> Saluti.
> Emanuele.
Funziona, però devi cambiare le barre nella data altrimenti s'incazza.
es. -- "listino_" & format(date(),"dd_mm_yy")
rimane però il problema del formato word, questo non credo sia risolvibile
perchè esistono solo questi di formatooutput
acFormatASP
acFormatHTML
acFormatIIS
acFormatRTF
acFormatTXT
acFormatXLS



title: Creazione automatica file

text:
"Xymox" <
marco.santi...@libero.it
> ha scritto
> rimane perň il problema del formato word
Cmq cosě funziona, quindi č risolto anche questo :-)
  DoCmd.OutputTo acOutputReport, "R_Mag_Off", acFormatRTF, "c:\temp\" &
"OffRicambi_" & Format(Date, "dd_mm_yy") & ".doc", True


title: Creazione automatica file

text:

Ok, grazie, funziona...
Mi sapete dire se excel gestisce anche l'invio di email con allegato?



title: Creazione automatica file

text:
On Thu, 06 Mar 2003 20:15:39 GMT, "\(¯`·.¸Insecta¸.·´¯\)"
<opet...@NOSPAMhotmail.com> wrote:
>Xymox <
marco.santi...@libero.it
> wrote:
>> "Xymox" <
marco.santi...@libero.it
> ha scritto
>>
>>> rimane però il problema del formato word
>>
>> Cmq così funziona, quindi è risolto anche questo :-)
>>
>>   DoCmd.OutputTo acOutputReport, "R_Mag_Off", acFormatRTF, "c:\temp\"
>> & "OffRicambi_" & Format(Date, "dd_mm_yy") & ".doc", True
>
>Ok, grazie, funziona...
>Mi sapete dire se excel gestisce anche l'invio di email con allegato?
>Grazie,
> Mauro
>
>- - - - - - - - -
>Il mondo si divide in 10 tipi di persone: quelle che capiscono il codice
>binario e quelle che non lo capiscono
>- - - - - - - - -
>Visitate
www.insecta.it
>
in teoria tramite automazione puoi farlo anche su excel come su access
Saluti.
Emanuele.


title: Creazione automatica file

text:
Emyr <
fan...@tiscali.it
> wrote:
> On Thu, 06 Mar 2003 20:15:39 GMT, "\(¯`·.¸Insecta¸.·´¯\)"
> <opet...@NOSPAMhotmail.com> wrote:
<CUT>
>> Ok, grazie, funziona...
>> Mi sapete dire se excel gestisce anche l'invio di email con allegato?
>> Grazie,
>> Mauro
>>
>
>
>
> in teoria tramite automazione puoi farlo anche su excel come su access
> Saluti.
> Emanuele.
Ops... ho scritto una fesseria... volevo chiedere se access gestisce l'invio
di e-mail...



title: Creazione automatica file

text:
On Fri, 07 Mar 2003 09:53:58 GMT, "\(¯`·.¸Insecta¸.·´¯\)"
<opet...@NOSPAMhotmail.com> wrote:

vedi sendobject e
sitocomune.com
Saluti.
Emanuele.


title: Creazione automatica file

text:

Emanuele mio se ti vedesse Biso Il Savonarola (inteso come fustigatore di
malcostumi)...
perchè apri altri 3d???
ciao MAssimiliano



title: Creazione automatica file

text:
On Fri, 07 Mar 2003 11:40:21 GMT,
massimilia...@kksrl.com
 (MA)
wrote:
>> vedi sendobject e
sitocomune.com
>> Saluti.
>> Emanuele.
>
>Emanuele mio se ti vedesse Biso Il Savonarola (inteso come fustigatore di
>malcostumi)...
>perchè apri altri 3d???
>
>ciao MAssimiliano
in che senso scusa?
non ho aperto altri 3d
Saluti.
Emanuele.


title: Creazione automatica file

text:
Emyr <
fan...@tiscali.it
> wrote:
> On Fri, 07 Mar 2003 09:53:58 GMT, "\(¯`·.¸Insecta¸.·´¯\)"
> <opet...@NOSPAMhotmail.com> wrote:
>
<CUT>
> vedi sendobject e
sitocomune.com
> Saluti.
> Emanuele.
Ok, grazie, forse ho trovato quello che mi serviva...
Ora è solo da implementare...
Ciao,



title: Creazione automatica file

text:

Allora c'è qualcosa che non va sul tuo pc. Non sarà questo Win e OXp di cui
ti stai dichiarndo sempre di più estimatore. Infatti l'hai appena rifatto.
Controlla magari via usenet.



title: Creazione automatica file

text:

Vedi che a me compare regolarmente sotto il thread... Non è uno nuovo...
Ciao,
 Mauro
> --------------------------------
> Inviato via
http://usenet.libero.it
--



title: Creazione automatica file

text:
On Fri, 07 Mar 2003 14:39:27 GMT,
massimilia...@kksrl.com
 (MA)
wrote:

forse piuttosto il fatto che uso free agent, da me questo è un 3d
unico
Saluti.
Emanuele.


title: Creazione automatica file

text:

Anche questo è staccato.
Pagalo meglio questo tuo agent magari così lavora meglio.
