Блог

Простой вопрос: возможно ли использовать C # вместо VBA для MS Access? Могу ли я расширить приложения Access с помощью Windows forms и (или) WPF? Будет ли такой сценарий иметь смысл?

Да, вы можете написать приложение с графическим интерфейсом на C #, затем нажать кнопку MSAccess (или меню) и перейти к приложению C #, передавая контекстную информацию в командной строке (например, имя базы данных, открываемую форму, идентификатор записи и т.д.).

В качестве альтернативы вы можете предоставить COM-интерфейс своему приложению, чтобы использовать CreateObject для создания форм или доступа к другим функциональным возможностям.

Вам будет очень сложно вернуться другим путем, чтобы получить доступ к вашим формам MSAccess и отчетам из приложения C #, но это можно сделать с помощью COM или Windows Sockets).

Вы, конечно, можете просто написать приложение с графическим интерфейсом C # с базой данных MSAccess в серверной части и не использовать никаких форм MSAccess (ПРИМЕЧАНИЕ, если можете и решите не использовать какие-либо аспекты графического интерфейса MSAccess, тогда я бы настоятельно рекомендовал использовать полностью другую базу данных, такую как SQL Lite или SQL Express).

Надеюсь, это поможет.

Обновление В ответ на Зачем кому-либо делать что-либо из этого? В чем смысл?

База данных MSAccess ужасно масштабируется. Я видел, как хорошо написанное приложение Access страдало от повреждения и проблем с целостностью данных у 4 или 5 пользователей. Гарантированная скорость и стабильность сети оказывают влияние, но на самом деле проблема заключается в доступе (приложения SqlExpress лучше масштабируются в худших сетях). Смотрите Ограничения MSAccess

Из Насколько масштабируемым является MS Access

Access на самом деле не имеет места ни в одном значимом проекте базы данных. В основном он ориентирован на домашний рынок для людей, которые хотят иметь возможность хранить информацию для домашнего использования без необходимости изучать продвинутый Excel для этого

Из статьи Inform IT, где они посвящают большую часть статьи объяснению того, почему вы должны использовать MSAccess, они добавляют (это мой акцент)

• Масштабируемость. Access не может легко обрабатывать очень большие базы данных. Вообще говоря, чем больше база данных, тем тщательнее должно быть разработано приложение Access.
• Сеть. Хотя Access — это многопользовательская база данных со встроенной блокировкой записей и другими функциями транзакций, она плохо работает по сети

Серьезно, чувак? «это плохо работает по сети» В наши дни, когда распределенные вычисления — следующая большая вещь, — что, черт возьми, в этом хорошего? Итак, в принципе, если только одному пользователю на одном компьютере нужно использовать приложение, тогда все в порядке, но если есть шанс, что вам нужно распространить это на нескольких пользователей, зачем тратить время и усилия на его создание в Access, чтобы развернуть его, вам нужно будет заново собрать приложение have и реальную СУБД на серверной части.

Действительно, вам лучше вообще не использовать Access, если, конечно, вы не единственный человек в мире и у вас единственный компьютер 🙂

Ну,

если вы не хотите использовать VBA от Acces (и, я думаю, все связанные объекты, такие как формы, модули и т.д.), Я думаю, вам лучше вообще не использовать Access. Храните свои данные в любом «реальном» движке базы данных, бесплатном или нет (SQL Express, MySQL и т.д.) И создайте свой пользовательский интерфейс на вашем любимом языке.

Вы можете использовать C # для управления всем в Access, но это кажется полным перебором. Я бы подумал, что VBA может обрабатывать любые требования, а с помощью VBA вы даже можете создавать пользовательские функции в Access, чтобы делать то, что было бы невозможно, используя только стандартные встроенные инструменты Access. Опять же, если вы хотите использовать C # для управления доступом, да, вы, безусловно, можете это сделать.

Вот хорошая ссылка, которая поможет вам начать.

http://csharp.net-informations.com/data-providers/csharp-oledb-connection.htm

Внизу этой страницы есть множество других ссылок, которые должны помочь вам во многих других вещах.

Конечно, вы можете это сделать. Вы можете сделать так много вещей, когда интегрируете C # и Access. Например, вот способ загрузить GridView из 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";
        }
    }
}
  

Взгляните на ссылку ниже, чтобы получить еще несколько идей о том, что можно сделать с C # и Access.

https://www.codeproject.com/Articles/1060352/Using-Microsoft-Access-Database-In-Csharp-ADO-NET

Хотя…………Я должен сказать, что вы, вероятно, никогда не избавитесь от VBA. Кроме того, VBA — это низко висящий фрукт. Намного проще использовать VBA с Access, чем пытаться приручить C # делать по существу то же самое, что VBA сделал бы для вас. Кроме того, VBA, вероятно, намного больше ограничивает, а C # будет намного более гибким с точки зрения того, чего вы можете достичь.