volendo passare dall'accesso ms, pensando .net? studio visivo?

Question

Così ho scritto un programma di gestione del progetto per una piccola impresa che utilizza Microsoft Access 2007.

sacco Ora hanno richiesto di funzionalità aggiuntive (cronometraggio, i livelli di dati privilegiati ...)

io personalmente uso di Linux , ma l'intero ufficio utilizza Windows.

Sono relativamente nuovo per la programmazione, ma, come per insegnare a me stesso che usano progetti come questo.

Sono proprio al limite di questo - Non posso davvero dire quale sia il percorso di minor resistenza qui: rimango in accesso + VBA e mi insegno un linguaggio morente e fastidioso - mentre sto lottando contro tutte le limitazioni di accesso? O mi trasferisco a qualcos'altro?

Python sembra abbastanza semplice ... Qualunque cosa che uso, ho bisogno di essere in grado di offrire una GUI.

screenshot in modo da poter ottenere il jist: http://img707.imageshack.us/img707/9360/screenshot1fi.jpg

http://img707.imageshack.us/img707/7338/screenshotmh.jpg

- note: progetto di Access corrente utilizza separato frontend-backend per la condivisione multiutente su una LAN

compatibilità cross con Linux non è così importante per me, sto usando virtualbox da un po 'di tempo.

--UPDATE-- le mie peregrinazioni mi hanno convinto che avrei dovuto procedere in IronPython - comunque - mentre provo ad installare la suite sia in XP che in 7, e fallisco ... Mi chiedo se anche questo sia qualcosa di obsoleto ... soprattutto, iv'e state leggendo su di esso e mi piace Python 3 - ma ho bisogno di offrire un'interfaccia grafica per Windows non sai da dove cominciare con quello (compreso che IDE da utilizzare, ecc)

Answer 1

VB e C# sono certamente simile a quella di accesso, e sarebbe bene se si sta cercando di non spostare troppo lontano.

Python è brillante ma non come Access. È semplicemente un linguaggio di programmazione che ha buone librerie db. Le librerie della GUI sembrano piuttosto buone anche se non le ho mai usate. Il design della GUI sarà più difficile in Python di C#/VB. Python è gratuito e può valere la pena solo sperimentare con ie. costruire una GUI, connettersi a un database SQLite. Probabilmente otterrai una buona indicazione della fattibilità dell'uso di Python per i tuoi scopi.

Non rimanere esclusivamente con Access. L'accesso è abbastanza buono per le piccole applicazioni e puoi fare alcune cose molto velocemente. D'altra parte VBA è brutale e sta limitando severamente. Prova sia C# che Python se puoi.

Answer 2

In un ambiente del genere, non si può sbagliare con VB/C#. Prova le varie edizioni VS Express.

Se si desidera qualcosa che si traduca in Linux un po 'di più, Python e praticamente qualsiasi framework GUI multipiattaforma (QT o wxpython) funzionerebbe.

MODIFICA: Poi c'è il database. Probabilmente suggerirei sqlite se vuoi imparare qualcosa di multipiattaforma. Rimanendo nel mondo Microsoft, c'è SQL Server Compact.

In un ambiente aziendale simile, un'applicazione .NET è probabilmente più manutenibile (dopo che sei sparito, ecc.) Quindi tutto ciò che non è completamente Microsoft.

Answer 3

Fintantoché i client non condividono un database, un'applicazione .NET WPF/WinForms con un DB incorporato sembra funzionare correttamente.

Probabilmente potresti anche sviluppare qualcosa che funziona su entrambi i PC Windows e la tua macchina Linux usando Mono (verrai bloccato con un sottoinsieme di WinForms ... ma per una semplice app business, non c'è davvero niente di sbagliato in questo) .

Answer 4

Hai pensato a Appcelerator Titanium oa qualcosa di simile? Si crea una GUI ricca utilizzando tecniche web (HTML, CSS, javascript e o python) e la si compila in un'applicazione desktop.

Il vantaggio è che è possibile sviluppare su Linux e eseguire solo la distribuzione finale del test & su Windows.

Detto questo, scrivere un software di produzione come principiante non è facile. Soprattutto gli errori di gestione possono essere difficili. Sii intelligente e pensa a "Cosa può andare storto quando l'utente fa questo" fino in fondo e convalida l'input.

Answer 5

direi web app (C#) con SQL Express sul back-end - ma questo è solo me

Answer 6

WPF ha una curva di apprendimento piuttosto ripida, soprattutto provenienti da Access. WinForms sarebbe un percorso più semplice, ma è ancora un salto da Access. Tuttavia, sia WPF che WinForm hanno una costruzione di moduli drag-and-drop e, presumendo che tu abbia imparato abbastanza VB.NET per convertire la logica di business VBA, sei più che a metà strada. :)

Se si implementa il progetto in WPF, è possibile renderlo abilitato per Silverlight, ma si tratta di un intero tipo di worm.

Answer 7

MS Access è un'applicazione di database desktop. Probabilmente un passo avanti è SQL Server Compact Edition (SQLCE), che funziona come parte della tua applicazione (a differenza di SQL Server Express o superiore, che vengono eseguiti come servizi di sistema). Ho usato SQLCE con un grande successo in alcune applicazioni e Microsoft lo sta usando in Visual Studio 2010 per la nuova cache IntelliSense di Visual C++ perché è leggero e funziona alla grande.

Nonostante ciò che ho letto su alcune fonti, SQLCE non collabora bene con Entity Framework. Lo fa tuttavia funziona alla grande con LINQ-to-SQL e il progettista corrispondente. Detto questo, il mio consiglio personale è di prendere in considerazione che unisce il seguente come sostituzione:

• dati: SQL Server Compact Edition
• dati/Codice: LINQ to SQL
• Linguaggio di programmazione: C#
• Quadro dell'applicazione: WPF
  • Nota personale: WPF ha una curva di apprendimento, ma è principalmente difficile per le persone che hanno lavorato con altri framework (MFC, WinForms, ecc.) Per un lungo periodo. Raccogli una buona referenza e sarai produttivo in pochissimo tempo, in più sarai esperto in una tecnologia che le persone si stanno muovendo verso invece di via.

Answer 8

ho detto in un commento, ma lo ripeto come una risposta:

Se si guarda al futuro di Access, è luminoso. La SM sta investendo molto in essa. Access 2010 in collaborazione con Sharepoint 2010 offre alcuni vantaggi incredibili, e lo fai tutto senza VBA (invece usi i nuovi, potenti macro, che hanno variabili, branching e error trapping). È possibile farlo con Accesso client e senza SharePoint, oppure è possibile pubblicarlo su Sharepoint e l'applicazione viene eseguita nel browser web.

La mia supposizione è che una delle due cose stanno per accadere per quanto riguarda il linguaggio di programmazione in Access nell'arco di tempo delle versioni di Access 2-3 dopo il 2010:

1. VBA rimane sostenuta e tutta la il lavoro va in macro. Alla fine, le macro diventano il metodo preferito per tutte le programmazioni in Access, con VBA alla fine deprecato e infine eliminato. Perché da quel punto i macro sono così versatili e robusti, non il linguaggio di programmazione sostituirà VBA.

2. lo stesso scenario, tranne che .NET è stato introdotto come sostituzione per VBA.

spererei per 2 #, ma dipende interamente dal punto di vista di Microsoft di ciò che Access è, vale a dire, in primo luogo e strumento di utenti finali con estensibilità verso l'alto (# 1) o entrambi uno strumento di utenti finali e un strumento di sviluppo versatile con estensibilità illimitata (n. 2).

Il mio punto è che si può stare con Access, evitare VBA per ora (se proprio lo si odia), e probabilmente finire con un'app stabile e praticabile.

Tuttavia, le mie riserve sui macro sono molto forti, in quanto le trovo molto difficili da mantenere a causa della loro natura autonoma. Il codice VBA è abbastanza facile da navigare e capire, perché è compilato e perché c'è un IDE completo. I macro sono molto più compartimentati e difficili da tracciare le interrelazioni tra loro e gli oggetti in cui sono utilizzati. Aggiungi le macro incorporate aggiunte in A2007 e diventa ancora più complicato. Non so se il team di Access stia affrontando questo o no, ma per me è un vero passo indietro in termini di gestibilità, in particolare se il rafforzamento delle macro finisce per provocare la deprivazione di VBA e quindi non viene sostituita con un potente corrispondente linguaggio di programmazione con un buon IDE.

Infine, non ho detto nulla sul motore del database, poiché Access è completamente agnostico a questo riguardo, in grado di utilizzare Jet/ACE per iniziare e quindi di eseguire l'upsize sul motore di propria scelta. È un non-problema, mi sembra, dato che le tue opzioni sono spalancate quando usi Access come front-end.

Answer 9

In base ai vostri criteri, vorrei utilizzare PyGtk e Glade. Gtk è ben supportato su Windows e Linux, e ho ottenuto più risultati in meno tempo con Python e GTK, che con qualsiasi altra combinazione di linguaggio/toolkit.

Se si è disposti a ripensare a farlo sul web, dare un'occhiata a ExtJS, che fornisce un sacco di desktop come controlli web, e hanno un costruttore GUI.

Per il database vorrei utilizzare Postgresql o SQLite. Siate consapevoli del fatto che SQLite presenta alcune limitazioni severe in termini di concorrenza, il che potrebbe essere un problema a seconda della progettazione dell'applicazione e del numero di utenti.

Answer 10

Se sono solo piccole applicazioni interne su cui stai lavorando, dai un'occhiata a Visual WebGUI - ottieni un ambiente di sviluppo molto simile a VB6 per le app web.Non lo consiglierei comunque per applicazioni grandi e/o pubbliche.