Newsgroup: it.comp.appl.access
Titolo: due richieste per office 2021

la prima č la solita: implementare lo zoom nella struttura delle maschere e 
dei report, che non se ne puň piů di dover tirare fuori gli occhi per 
sistemare le cose piccole (no, il magnifier lo usate voi, grazie)
 
la seconda č la visualizzazione del codice VBA con il word-wrap, 
opportunamente evidenziato (no, il trucco di usare underscore-spazio andava 
bene venti anni fa, non oggi)
 
per oggi basta cosě, meglio non subissare microsoft di richieste
 
 
-- 
/-\ /\/\ /\/\ /-\ /\/\ /\/\ /-\ T /-\
-=- -=- -=- -=- -=- -=- -=- -=- - -=-
........... [ al lavoro ] ...........

 
 
 
andrebbe rifatto tutto l'editor vba...siamo a livelli di visual basic 
1.0 :-)
 
per lo zoom...ti accontenti di poco
io vorrei poter disegnare una form in xml con la stessa facilità degli 
ide più evoluti
 
e un ritorno a quello che erano i vecchi adp con cui si lavorava con 
sqlserver direttamente da dentro access.. ed era una meraviglia
 
BFS

 BFS
 
Temo infatti, ed ovviamente è una considerazione personale, che dietro a queste cose ci sia una accuraa strategia di prodotto... che orienta o vorrebbe orientare il pubblico professionale ad abbandoare Access per accettare NET a tutti gli effetti, e circoscrivere la fruizione della Suite Office ad un pubblico di minor impatto tecnico.
Ne sono prova i continui rumors che si susseguono negli anni di dismissione di Access, puntualmente smentiti, ma sicuramente creati a dovere, il bacino è ancora troppo rilevante ma si cerca di ridurne il peso.
 
Come strategia di Casa MS, la posso comprendere, non mi piace... ma far rientrare il processo di evoluzione in binari predefiniti sicuramente agevola il lavoro alla MS e riduce i costi di sviluppo, il lavoro sporco di dover portare avanti prodotti che stanno facendo diventare di "nicchia"...
 
Il Passaggio a NET in parte è automatico, molti sviluppatori lo fanno in autonomia, ma ovviamente arrivare ad essere produttivi con un nuovo linguaggio non è immediato, serve qualche anno credo ad avere la medesima dimestichezza/autonomia/garanzia, e questo lo si può ragionevolmente pensare per NUOVE applicazioni, ma il problema più serio è il mantenimento del parco clienti ed Applicazioni precedenti.
 
Francamente, non conosco aziende che si mettono a rifare applicativi di clienti consolidati per passare da Access a Net... solo a titolo di studio... ;-), poicheè a titolo "oneroso" penso sia veramente oneroso... 
Basti solo pensare al carico di lavoro aggiunto, su cui temo che sia più facile fare una patta se va veramente bene...
 
Tema che penso si possa prestare a considerazioni importanti e molto vaste nell'insieme...
 
@Alex

 Francamente, non conosco aziende che si mettono a rifare applicativi di clienti consolidati per passare da Access a Net... solo a titolo di studio... ;-), poicheè a titolo "oneroso" penso sia veramente oneroso... 
 
E' un problema di carattere generale, tanto è vero che a tutt'oggi restano attive molte installazioni AS400, con relative applicazioni sviluppate in ...  RPG e Cobol.
Rifare i software aziendali non è mai un giochino.
 
Saluti.
 
P:S:  Però non concordo sulla nostalgia per i files .ADP: non avrebbero mai dovuto introdurre in Access quei baracconi ultra-buggati, buoni forse per assegnare un tapirone d'oro agli ideatori degli "snapshot aggiornabili" delle Forms.


"ultra buggati" ?
 
ho alcune applicazioni di contabilità molto complesse sviluppate ancora 
con adp xp che girano una meraviglia pure con sql server 2019 come BE e 
windows 11 come s.o.
mai un db corrotto o un dato perso
fossero tutti cosi buggati i software MS :-)
 
 
 
 

 fossero tutti cosi buggati i software MS :-)
 
 
Guarda, di problemi ne avevano molti (chiaramente mi riferisco alla fase di Design e programmazione): noi ci investimmo tempo e risorse (principalmente Access 2000) ma fu un macello.
Tipi di Dati supportati da SQLSVR inutilizzabili in ADP/VBA, bugs di programmazione da aggirare in continuazione, impossibilità di connessione in scrittura ad altri formati di Database (ma come fai a chiamare "ACCESS" un prodotto siffatto?),  conseguente impossibilità nel creare banalissime tabelle temporanee localmente, Recordsets 'snapshot aggiornabili' inadatti per Forms oltre le centinaia di records (si scaricavano tutto il pacco in background a velocità bradipesche), se ben ricordo era perfino macchinoso agganciare una distribuzione Runtime al Server SQL.
 
Non mi stupisco che li abbiano abbandonati, ma piuttosto che li abbiano ideati in quel modo.
Se n'è discusso spesso sul ng. tra chi li ha amati e chi li ha odiati considerandoli un controsenso, io appartengo alla seconda.
 
Saluti.
 
 
 
 
 

   bugs di programmazione da aggirare in continuazione, impossibilità di connessione in scrittura ad altri formati di Database (ma come fai a chiamare "ACCESS" un prodotto siffatto?),  conseguente impossibilità nel creare banalissime tabelle temporanee localmente, Recordsets 'snapshot aggiornabili' inadatti per Forms oltre le centinaia di records (si scaricavano tutto il pacco in background a velocità bradipesche), se ben ricordo era perfino macchinoso agganciare una distribuzione Runtime al Server SQL.
 
di tutto ciò mai visto nulla
sopratutto del "si scaricavano tutto il pacco in background a velocità 
bradipesche"...anzi le prestazioni sono ancora sbalorditive
 
sarò stato fortunato
 
 
 


O sei stato fortunato, oppure parliamo di cose diverse.
 
Saluti.


Sulla questione del pacco dati in background... francamente resto stranito pure io..., se me lo dicesse un'altro risponderei che l'origine Record includeva riferimenti non risolvibili ServerSide... come FORMS!NomeForm!NomeControllo/Dcount/EVAL e quanto altro non riconoscibile dal ServerEngine..., ma dal momento che sei tu, e so che quanto ho esposto sono banalità ... la cosa mi lascia molto perplesso...
 
Io ricordo che feci a suo tempo, parecchie comparazioni di performances anche sulla navigazione delle Form DataBound, una anche con Giorgio Rancati che ai tempi era pieno sostenitore dìi ADP, su Form associate a SP Parametriche con e senza appoggiarsi a Filter di Form, e risultavano sempre più performanti in ADP che Form con Filtri con DAO.
Le prove erano eseguite su basi dati importanti come mole, che appunto rendevano l'idea delle Performances temporali.
In quei casi anche l'analisi fatta con SQL_Server Managment in nessun caso rilevava quanto affermi, salvo appunto impossibilità di risoluzione del predicato lato Server..., in quel caso il Driver DAO era sicuramente più performante, ed i dati restituiti erano tutto l'intero Recordset in locale, e poi l'applicazione del criterio da parte del Driver di JET.
 
Però mi fermo quì in quanto ho fatto sicuramente vari esperimenti anche molto approfonditi, ma nulla di più impegnativo.
 
@Alex


mi sa che parliamo di cose diverse
 
esempio
file adp sempre uguale dal 2002 a oggi, nato per MSDE/SQL2000 e che 
ancora oggi connetto a sql più recenti e non da problemi
 
classica maschera di ricerca articoli
articoli 145.000 ma ho clienti con ferramenta che ne hanno 5 volte tanti
database su sql server 2017 su cloud aruba
client file adp su pc I3 4gb di ram
adsl 4 mbit
 
questa è la bradipesca velocità pur non avendo il db sql in lan:
 
http://youtu.be/g1nDdEycv1A?hd=1
 
 
 
per le tabelle temporanee sql server ha un db apposito per crearti tutte 
quelle che ti servono...
 
per il runtime/sql server
in fase di apertura fai la classica connessione..due righe di codice
nulla da installare in più rispetto al runtime per un mdb
 
bugs di programmazione...boh
 
 
BFS


 
Premesso che i problemi degli .ADP sono testimoniati da molti vecchi post rintracciabili sui ng. ma che sono lustri che non ci lavoro, ricordo bene che la logica stessa d'apertura di una tabella/qry di grandi dimensioni era "particolare": anzichè visualizzare istantaneamente la prima "pagina" di dati, e recuperare poi le successive durante lo scrolling o eventuali Filtri, il sistema scaricava tutti i records (con comodo) sul Client, con tanto d'indicazione del numero di righe trasferite in background.  Forms agganciate a origini dati impegnative si comportavano in tal modo.
Ma questo era solo uno dei tanti inghippi ... tu sei mai riuscito a collegarti da un ADP a un altro Server di database in scrittura?  (coi server collegati si poteva solo leggere)
 
Saluti.
 
 

 nulla da installare in più rispetto al runtime per un mdb 
 
Passato molto tempo, ma ricordo problemi di connessione con .ADE eseguiti in Runtime  (forse risolti con aiuto di Giorgio Rancati).  
 
Saluti.
 

 
 
 
 
i miei clienti che li usano ancora hanno ovviamente .ADE e non ADP
problemi di connessione mai visti
 
la connessione è tutta qua:
 
 
Function fChangeADPConnection(strServername, strDBName As String, 
Optional strUN As String, _
         Optional strPW As String) As Boolean
'------------------------------------------------------------
'This Function resets the connection for an ADP by using the
'input parameters to create a new connection string. If no username
'is supplied, it tries to connect by using integrated security.
'
'Input:
'   strServerName    The server to be started
'   strDBName   The Name of the MSDE Database
'   strUN        The user used to start server
'   strPW        The password of user
'------------------------------------------------------------
     Dim strConnect As String
     On Error GoTo EH:
     strConnect = "Provider=SQLOLEDB.1" & _
     ";Data Source=" & strServername & _
     ";Initial Catalog=" & strDBName
     adp_UseIntegratedSecurity = False
     If Len(strUN) = 0 Then
         adp_UseIntegratedSecurity = True
     End If
     If adp_UseIntegratedSecurity = True Then
         strConnect = strConnect & ";integrated security=SSPI"
     Else
         strConnect = strConnect & ";user id=" & strUN
         strConnect = strConnect & ";password=" & strPW
     End If
     Application.CurrentProject.OpenConnection strConnect
     fChangeADPConnection = True
     Exit Function
EH:
     MsgBox err.Number & ": " & err.Description, vbCritical, "Connection 
Error"
     fChangeADPConnection = False
End Function
 
 
 
vabbè
io sono tra quelli che farebbe i salti di gioia perchè tornassero.
probabilmente l'essere a favore o contro dipende dal successo che si ha 
avuto con quel tipo di formato.
io ne posso solo parlare bene, 20 anni che non mi creano una minima 
rogna e prestazioni ancora oggi fenomenali
 
BFS
 
 

 problemi di connessione mai visti 
 
 
Mah, può essere che fosse Access 2000 Runtime con (o senza) uno dei 20.000 relativi S.Pack a darci noie: ricordo che s'impazziva.
Comunque prendo atto della tua soddisfazione sul prodotto.
 
Saluti
 

 Quando inizi un lavoro non puoi sapere a priori quali saranno gli sviluppi futuri e imho l'idea di concepire un ambiente di Editing da Access per il solo SQLSVR (oltretutto incompatibile, se ricordo, con le versioni più vecchie del Server SQL) era limitante.
 
scusa dov'è il problema a leggere/scrivere "comunicare" dati da un adp 
su altro applicativo?
 
da dei file adp/ade io leggo e scrivo dati su un software di timbratura 
che usa mdb
 
sincronizzo un e-commerce leggendo e scrivendo direttamente in mysql nel web
 
leggo e scrivo dati sul software del centralino telefonico che usa sql 
portable
 
quando ho la connection string leggo e scrivo dove voglio. forse intendi 
il fatto di non poter linkare la tabella...ma non è una gran mancanza per me
 
per il discorso versione vecchie sql server
mi pare che il formato sia nato con MSDE/SQL2000...quindi mi pare 
normale che con le più vecchie non vada
 
ma da quella versione alla 2019 express ancora gira
 
bon dai basta altrimenti sembra che sia stipendiato da MS
sono solo stato fortunato con questo formato
 
 
"adp è morto, lunga vita a adp"
 
BFS
 
 

 sono solo stato fortunato con questo formato 
 
In realtà è stato amato da tanti 'accessisti', quindi è evidente che la differenza d'opinioni è molto legata al tipo di applicazioni e alle difficoltà incontrate all'uscita del prodotto.
 
Saluti.