Una semplice domanda: è possibile utilizzare C# invece di VBA per MS Access? Posso estendere le applicazioni di Access con i moduli di Windows e (o) WPF? Uno scenario del genere avrebbe senso?MS Access senza VBA?
risposta
Sì, è possibile scrivere un'app GUI in C#, quindi fare clic con il pulsante MSAccess (o menu) shell sull'app C#, passando le informazioni di contesto sulla riga di comando (ad es. Nome del database, modulo da aprire, ID del record , eccetera).
In alternativa, è possibile esporre un'interfaccia COM all'applicazione, quindi è possibile utilizzare CreateObject per creare moduli o accedere ad altre funzionalità.
Troverai molto difficile tornare indietro, per accedere ai moduli di MSAccess con i rapporti & dall'applicazione C#, ma è possibile farlo utilizzando COM o Windows Sockets.
Ovviamente si può solo scrivere un C# applicazione GUI con il database MSAccess nel back-end, e non utilizzare alcuna forma MSAccess (NB Se possono e decidere di non utilizzare tutti gli aspetti del MSAccess GUI, poi ho' d consiglia vivamente di utilizzare un database diverso interamente come SQL Lite o SQL Express).
Spero che questo aiuti.
Aggiornamento In risposta a Perché qualcuno dovrebbe fare nulla di tutto ciò? Qual e il punto?
Il database di MsAccess scala in modo terribile. Ho visto un'app di accesso ben scritta che soffre di problemi di corruzione e integrità dei dati con 4 o 5 utenti. La velocità e la stabilità garantite della rete hanno un effetto, ma in realtà il problema è l'accesso (le app SqlExpress si adattano meglio alle reti peggiori). Vedere Limitations of MsAccess
accesso in realtà non hanno un posto nel qualsiasi progetto di database significativa. E è fondamentalmente destinato al mercato di casa per le persone che vogliono essere in grado di negozio informazioni per l'uso domestico, senza dover imparare avanzata Excel per farlo
Dal Inform IT articolo, dove passano gran parte del l'articolo che ti dice perché si dovrebbe usare MsAccess, aggiungono (questo corsivo è mio)
- Scalabilità. L'accesso non gestisce facilmente i database molto grandi . In generale, più grande è il database , più accuratamente l'applicazione di accesso deve essere progettata per .
- Rete.Anche se l'accesso è un database multiutente con built-in blocco record e altre funzioni transazionali, non lavoro ben più di una rete
"non funziona bene su una rete"Davvero un tipo? In questo giorno ed età - con il calcolo distribuito il next big - che diavolo è buono? Quindi, se solo un utente su un computer ha bisogno di usare l'app, allora va bene, ma se c'è una possibilità devi distribuirla a più utenti, perché spendere il tempo e gli sforzi per costruirla in Access, per eseguilo, dovrai ricostruire l'app e un vero RDBMS nel back-end.
Davvero tu sei meglio non utilizzando Access, in primo luogo a meno che naturalmente tu sei l'unica persona al mondo e si ha l'unico computer :)
Beh,
se non si desidera utilizzare VBA di Acces (e credo che tutti gli oggetti correlati come moduli, moduli, ecc.), Suppongo che è meglio non usare affatto l'accesso. Memorizza i tuoi dati in qualsiasi motore di database "reale", gratuito o meno (SQL Express, MySQL, ecc.) E crea l'interfaccia utente nella tua lingua preferita.
Non capisco perché la gente pensa che sia più facile e veloce costruire applicazioni di database usando strumenti di sviluppo generici. –
È possibile utilizzare C# per controllare tutto in Access ma sembra un completo overkill. Penserei che VBA possa gestire qualsiasi/tutte le richieste e con VBA puoi persino creare funzioni personalizzate in Access per fare cose che sarebbero impossibili usando solo gli strumenti di accesso integrati standard. Di nuovo, se vuoi usare C# per gestire Access, sì, puoi certamente farlo.
Ecco un buon collegamento per iniziare.
http://csharp.net-informations.com/data-providers/csharp-oledb-connection.htm
Ci sono un sacco di altri link in fondo alla pagina che dovrebbe aiutare con molte altre cose.
Certo che puoi farlo. Puoi fare tante cose quando integri C# e Access. Ad esempio, ecco un modo per caricare un GridView da Access.
using System;
using System.Data;
using System.Windows.Forms;
using System.Data.OleDb;
namespace WindowsApplication1
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
private void button1_Click(object sender, EventArgs e)
{
string connetionString = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=your .mdb file;";
string sql = "SELECT * FROM Authors";
OleDbConnection connection = new OleDbConnection(connetionString);
OleDbDataAdapter dataadapter = new OleDbDataAdapter(sql, connection);
DataSet ds = new DataSet();
connection.Open();
dataadapter.Fill(ds, "Authors_table");
connection.Close();
dataGridView1.DataSource = ds;
dataGridView1.DataMember = "Authors_table";
}
}
}
Dai uno sguardo al link sottostante per ulteriori idee su cosa può essere fatto con C# e Access.
https://www.codeproject.com/Articles/1060352/Using-Microsoft-Access-Database-In-Csharp-ADO-NET
Anche se ............ devo dire, probabilmente non avrai mai allontanarsi da VBA. Inoltre, VBA è il frutto a bassa attaccatura. È molto più facile usare VBA con Access piuttosto che provare a domare C# per fare essenzialmente la stessa cosa che VBA farebbe per te. Inoltre, VBA è probabilmente molto più limitante, e C# sarà molto più flessibile, in termini di ciò che è possibile ottenere.
@Elmex al di fuori di quelle opzioni possibili, l'ultimo probabilmente ti darà i risultati migliori. Sarà più facile codificarlo e supportarlo perché non devi fare cose complicate per saltare avanti e indietro tra le app. Inoltre, gli utenti finali non avranno bisogno di accedere per l'esecuzione. Solo. NET, il tuo EXE (e le dipendenze DLL) e una connessione valida al database. – ray
Perché qualcuno dovrebbe fare nulla di tutto ciò? Qual e il punto? –
@ David-W-Fenton: ho modificato la mia risposta per rispondere anche alla tua domanda. –