MS Access 无需 VBA?

发布于 2024-11-08 18:24:29 字数 92 浏览 0 评论 0原文

一个简单的问题:MS Access 是否可以使用 C# 代替 VBA?我可以使用 Windows 窗体和(或)WPF 扩展 Access 应用程序吗?这样的场景有意义吗?

A simple question: Is it possible to use C# instead of VBA for MS Access? Can I extend Access applications with windows forms and (or) WPF? Would such a scenario make sense?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

夜巴黎 2024-11-15 18:24:29

是的,您可以用 C# 编写 GUI 应用程序,然后让 MSAccess 按钮(或菜单)单击 shell 到 C# 应用程序,在命令行上传递上下文信息(例如数据库名称、要打开的表单、记录 ID 等)。

或者,您可以向应用程序公开 COM 接口,以便您可以使用 CreateObject 创建表单或访问其他功能。

您会发现很难以其他方式返回来访问您的 MSAccess 表单和信息。来自 C# 应用程序的报告,但也可以使用 COM 或 Windows 套接字来完成。

您当然可以只编写一个在后端使用 MSAccess 数据库的 C# GUI 应用程序,而不使用任何 MSAccess 表单(NB 如果可以并且确实决定不使用 MSAccess GUI 的任何方面,那么我强烈建议使用完全不同的数据库,例如 SQL Lite 或 SQL Express)。

希望这有帮助。

更新回答为什么有人会这样做?这有什么意义?

MsAccess 数据库的规模非常可怕。我见过编写良好的 Access 应用程序在 4 或 5 个用户的情况下遭受损坏和数据完整性问题。当然,网络速度和稳定性会产生影响,但真正的问题是访问(SqlExpress 应用程序在网络较差的情况下可以更好地扩展)。请参阅MsAccess 的限制

来自 MS Access 的可扩展性如何

Access 并没有真正占据一席之地
任何重要的数据库项目。它
基本上是针对国内市场
对于那些想要能够
存储信息供家庭使用,无需
学习高级 Excel 来做到这一点

来自 Inform IT 文章,其中他们文章花了很多篇幅告诉您为什么应该使用 MsAccess,他们补充说(这是我的重点

  • 可扩展性。访问不处理
    轻松处理非常大的数据库。
    一般来说,越大
    数据库,越仔细
    访问应用程序必须是
    设计的。
  • 网络。虽然 Access 是一个
    内置多用户数据库
    记录锁定和其他
    交易功能,它没有
    在网络上工作得很好

“它在网络上工作得不好” 真的吗?在当今时代 - 分布式计算下一件大事--那到底有什么好处?
所以基本上,如果一台计算机上只有一个用户需要使用该应用程序,那么没关系,但如果有机会您需要将其推广给多个用户,为什么要花费时间和精力来构建它在 Access 中,要推出它,您需要重新构建应用程序并在后端拥有真正的 RDBMS。

事实上,您最好一开始就不要使用 Access 当然,除非您是世界上唯一的人并且您拥有唯一的计算机:)

Yes, you can write a GUI app in C#, then have MSAccess button (or menu) clicks shell out to the C# app, passing context information on the command line (e.g. Database name, form to open, ID of record, etc).

Alternatively, you can expose a COM interface to your application, so you can use CreateObject to create forms or access other functionality.

You'll find it very hard to go back the other way, to get access to your MSAccess forms & reports from the C# application, but it can be done using COM, or Windows Sockets).

You can of course just write a C# GUI application with the MSAccess database in the back end, and not use any MSAccess forms (NB If can and do decide not to use any aspects of MSAccess GUI, then I'd strongly recommend using a different database entirely such as SQL Lite or SQL Express).

Hope this helps.

Update In answer to Why would anybody do any of that? What's the point?

MsAccess database scale dreadfully. I've seen well written Access app suffer corruption and data integrity issues with 4 or 5 users. Granted network speed and stability has an effect, but really the problem is access (SqlExpress apps scale better with worse networks). See Limitations of MsAccess

From How scalable is MS Access

Access doesn't really have a place in
any significant database project. It
is basically aimed at the home market
for people who want to be able to
store info for home use without having
to learn advanced Excel to do it

From an Inform IT article, where they spend much of the article telling you why you should use MsAccess, they add (this emphasis is mine)

  • Scalability. Access doesn’t handle
    very large databases easily.
    Generally speaking, the larger the
    database, the more carefully the
    Access application has to be
    designed.
  • Networking. Although Access is a
    multiuser database with built-in
    record locking and other
    transactional features, it doesn't
    work well over a network

"it doesn’t work well over a network" Really dude? In this day and age - with distributed computing the next big thing - what the hell good is that?
So basically, if only one user on one computer needs to use the app, then that's ok, but if there's a chance you need to roll this out to multiple users, why spend the time and effort building it in Access, to roll it out you'd need to re-build the app have and a real RDBMS at the back end.

Really you're better off not using Access in the first place unless of course you're the only person in the world and you have the only computer :)

扎心 2024-11-15 18:24:29

好吧,

如果您不想使用 Acces 的 VBA(我猜想所有相关的对象,如表单、模块等),我想您最好根本不使用 Access。将您的数据存储在任何“真正的”数据库引擎中,无论是否免费(SQL Express、MySQL 等),并用您最喜欢的语言构建用户界面。

Well,

if you do not want to use Acces's VBA (and I guess all related objects like forms, modules, etc), I guess you'd better not use Access at all. Store your data in any 'real' database engine, free or not (SQL Express, MySQL, etc) and build your user interface in your favorite language.

ゞ花落谁相伴 2024-11-15 18:24:29

您可以使用 C# 来控制 Access 中的所有内容,但这似乎完全是多余的。我认为 VBA 可以处理任何/所有需求,并且使用 VBA,您甚至可以在 Access 中创建自定义函数来完成仅使用标准内置 Access 工具不可能完成的事情。再说一遍,如果您想使用 C# 来管理 Access,是的,您当然可以这样做。

这是一个很好的链接,可以帮助您入门。

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

该页面底部还有许多其他链接,可以帮助您完成许多其他事情。

You can use C# to control everything in Access but it seems like complete overkill. I would think VBA can handle any/all demands and with VBA you can even create custom functions in Access to do things that would be impossible using just standard built-in Access tools. Again, if you want to use C# to mange Access, yes, you can certainly do that.

Here is a good link to get you started.

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

There are lots of other links at the bottom of that page that should help you with many other things.

过期情话 2024-11-15 18:24:29

你当然可以这样做。当集成 C# 和 Access 时,您可以做很多事情。例如,以下是从 Access 加载 GridView 的方法。

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# 将更加灵活。

Of course you can do that. You can do so many things when you integrate C# and Access. For instance, here is a way to load a GridView from 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";
        }
    }
}

Take a look at the link below for some more ideas of what can be done with C# and Access.

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

Although............I have to say, you will probably never get away from VBA. Also, VBA is the low-hanging fruit. It's a whole lot easier to use VBA with Access rather than trying to tame C# to do essentially the same thing that VBA would do for you. Also, VBA is probable a lot more limiting, and C# will be a lot more flexible, in terms of what you can achieve.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文