dovrei scrivere un front end di accesso o un front end C#?

Attualmente ho un database di Access. C'è un back-end, e ci sono più utenti che usano questo database con il proprio front-end. La dimensione dei dati è molto piccola; tuttavia ci sono diverse forme che sono costantemente in uso.dovrei scrivere un front end di accesso o un front end C#?

Ho bisogno di migrare i dati su MySQL. Devo continuare a utilizzare un front-end Access o programmare il mio front-end C#? Perché uno dovrebbe essere migliore rispetto all'altro?

fonte

2010-08-02 l--' ' ' ' ' ' ---------' ' ' ' ' ' ' ' ' ' ' '

che tutto dipende dal budget, dal tuo attuale skillset, dal numero di moduli ... –

Quando dici "C# front-end" stai parlando di WinForms, WPF, ASP.NET WebForms, ASP.NET MVC o Silverlight? –

jesse, probabilmente winforms, la cosa più semplice possibile! –

Penso che tutti voi siate completamente pazzi o non conoscete una cosa dannata su Access.

È certamente vero che gli strumenti per l'upsize di SQL Server sono più facili da utilizzare di qualsiasi altro disponibile per l'upsize su MySQL. Ma la difficoltà di upsize non dovrebbe guidare la scelta del back-end, perché è una scelta unica. Scegli il tuo database di back-end in base a ciò che funziona meglio per te. Mentre SQL Server Express è gratuito, ha un numero di limitazioni che MySQL stesso non ha.

Come ho detto nei commenti, è possibile esportare una tabella di accesso a MySQL definendo un DSN per il proprio database MySQL e semplicemente utilizzando il comando ESPORTA nel menu File di accesso. I risultati non saranno necessariamente perfetti, quindi potrebbe essere necessario modificare i risultati, troncare la tabella MySQL e quindi inserire i dati reali una volta che le tabelle MySQL sono tutte a posto. Sì, questo è più lavoro rispetto agli strumenti di upsize di SQL Server, ma è ancora abbastanza facile da fare.

E non è qualcosa che devi andare subito al primo tentativo, né devi farlo più volte.

Se MySQL è il motore di database preferito per la tua app, quindi utilizzalo. Usare SQL Server interamente a causa degli strumenti di upsize più elaborati è davvero un caso di coda che scuote il cane!

fonte

2010-08-02 19:42:30

Ho appena provato un'esportazione ODBC in PostGreSQL. Il mio campo numerico autonumerico diventa un numero intero PostGres anziché seriale e non ha il vincolo principale. Gli indici su altri campi non sono stati riportati. Mi piace ancora il tuo suggerimento perché posso recuperare il DDL, modificarlo come necessario, rilasciare la tabella e ricrearlo. Questa è una grande vittoria per me rispetto a partire da zero in PostGres. Grazie. Sono curioso, ci sono meno modifiche quando esporti a MySQL? – HansUp

Dipende dalla versione di MySQL. Non l'ho fatto molto spesso, in realtà, quindi non ho dettagli reali. Gli strumenti di upsize di SQL Server possono anche sbagliare i tipi di dati, quindi è davvero un non-problema, mi sembra. –

Si consiglia di eseguire la migrazione a SQL Server anziché a MySQL. Potresti semplicemente eseguire l'upsize del database di Access su SQL Server e lasciare che gestisca il pesante sollevamento dei dati. I moduli di accesso possono continuare a essere il tuo front-end.

Per David Fenton in basso nei commenti: "Upsizing è un'operazione unica e la facilità di farlo non dovrebbe guidare la scelta del back-end". Penso che questa sia una buona argomentazione. Ho consigliato SQL Server per semplificare gli strumenti di upsize e esistenti, ma questa confutazione riporta MySQL nella mia immagine.

fonte

2010-08-02 01:57:39 duffymo

+1: SQL Server Express è gratuito e [2008 R2 supporta i database fino a 10 GB] (http://www.microsoft.com/express/database /) –

perché dici server sql invece di mysql –

Perché puoi accedere facilmente a SQL Server. In questo modo SQL Server gestisce tutte le attività di dati; L'accesso diventa una semplice interfaccia utente. – duffymo

Se si passa a SQL Server anziché a MySQL, è possibile sviluppare il front-end in C# e utilizzare le funzionalità LINQ integrate per accedere ai dati. Molto più semplice e gratificante di Access front-end con Visual Basic, Applications ;-)

fonte

2010-08-02 03:42:10 Lester

C# è molto più semplice di Access? Si prega di spiegare in modo molto più dettagliato. –

Se non conosci nessuna delle due lingue, ti consiglio di imparare C# su VB per le app. Non essere confuso, VB per le App è (molto) diverso da VB.NET. Non è una questione di "molto più facile", ma C# è più potente e potente di VB per le app, e sì, IMO C# è più facile da imparare e utilizzare rispetto a VB per le app. – Lester

Riscrivere il front-end renderà questo progetto più complicato, non più semplice. Migrare prima il back-end, quindi valutare se è necessario riscrivere l'interfaccia utente. Potrebbe essere necessario apportare alcune modifiche al codice per adattare l'accesso alla nuova origine dati back-end, ma questo sarà molto meno impegnativo di una riscrittura completa.

fonte

2010-08-02 19:50:18

dovrei scrivere un front end di accesso o un front end C#?

risposta

Problemi correlati