使用“最后尝试”的数据库连接

发布于 2024-11-19 03:56:41 字数 542 浏览 2 评论 0原文

有人可以启发我如何使用 try finally 处理数据库连接(和错误)吗? 最好的做法是什么? 见过各种风格,但我想知道什么是最好的方法。 表的打开应该放在 TRY 块中还是仅仅放在主连接中 细绳 ? 因为我通常将我的数据库(绝对数据库,access..)放在我的exe文件夹中 我想知道这方面的最佳方法...... 或者首先检查文件,例如...

if (FileExists(sDatabasePath)) then begin
    ADOConnection1.ConnectionString:='Provider=Microsoft.Jet.OLEDB.4.0;Data Source='+sDatabasePath+';Persist Security Info=False';
    try
        ADOConnection1.Connected:=True;
        ADOTable1.Open;
    except
        ShowMessage ('cant access the database !');
    end;
end;

???

Can someone enlighten me on handling the database connection (and errors) using try finally ?
What would be the best practice ?
Seen various styles but I wonder what would be the best approach.
Should opening of the tables be put in TRY block or just the main connection
string ?
Since I usually put my database (absolute database,access..) in my exe folder
I was wondering about the best approach on this...
Or first check for file like ...

if (FileExists(sDatabasePath)) then begin
    ADOConnection1.ConnectionString:='Provider=Microsoft.Jet.OLEDB.4.0;Data Source='+sDatabasePath+';Persist Security Info=False';
    try
        ADOConnection1.Connected:=True;
        ADOTable1.Open;
    except
        ShowMessage ('cant access the database !');
    end;
end;

???

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

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

发布评论

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

评论(2

失与倦" 2024-11-26 03:56:41

注释:

  • 永远不要吞下异常,就像您在 ShowMessage 案例中所做的那样。调用您的过程的代码无法知道出了什么问题。仅在可以修复错误时才处理错误,或者让它们在应用程序错误处理程序中冒泡,并在其中向用户显示错误。
  • 根据代码的工作方式,您可能希望使用 try-finally 保护与数据库的连接,以便在作业完成后断开连接。我不这样做,我通常在应用程序的生命周期内保持连接打开。
  • 根据您对 ADOTable1 执行的操作,您可能希望确保在与其他 try-finally 块一起使用完它后将其关闭。我通常这样做是因为我不使用 Db 感知的 GUI 控件,而且我是一个控制狂。我也手动处理事务(启动事务/提交/回滚)
  • 不要忽略错误。如果您的数据库不存在(即:FileExists() 返回 false),则调用您的过程的代码不知道任何事情,用户也不知道。

这是我重写你的代码的方式:

if (FileExists(sDatabasePath)) then 
  begin
      ADOConnection1.ConnectionString:='Provider=Microsoft.Jet.OLEDB.4.0;Data Source='+sDatabasePath+';Persist Security Info=False';
      ADOConnection1.Connected:=True;
      try
        ADOTable1.Open;
        try
          // Do non-GUI database stuff here.
        finally ADOTabel1.Close;
        end;
      finally ADOConnection1.Connected := False;
      end;
  end
else
  raise Exception.Create('Database file not found');

Comments:

  • Never swallow exceptions, like you essentially do in your ShowMessage case. The code calling your procedure would have no way of knowing something went wrong. Only handle errors if you can fix them, or let them bubble-up the application error handler, where they'll be displayed for the user.
  • Depending on how your code works, you might want to protect the connection to the database with a try-finally so you're disconnected once the job is done. I don't do that, I usually keep the connection open for the life of the application.
  • Depending on what you do with the ADOTable1 you might want to make sure it gets closed once you're done using it with an other try-finally block. I usually do that because I don't use Db aware GUI controls and I'm a control-freak. I also handle the transaction manually (start transaction / commit / rollback)
  • Don't ignore errors. if your database doesn't exist (ie: FileExists() returns false), code calling your procedure doesn't know a thing, nor does the user.

Here's how I'd re-write your code:

if (FileExists(sDatabasePath)) then 
  begin
      ADOConnection1.ConnectionString:='Provider=Microsoft.Jet.OLEDB.4.0;Data Source='+sDatabasePath+';Persist Security Info=False';
      ADOConnection1.Connected:=True;
      try
        ADOTable1.Open;
        try
          // Do non-GUI database stuff here.
        finally ADOTabel1.Close;
        end;
      finally ADOConnection1.Connected := False;
      end;
  end
else
  raise Exception.Create('Database file not found');
痴情换悲伤 2024-11-26 03:56:41

如果我无法打开数据库,我会终止应用程序 - 如果没有数据库访问,您将无能为力,除非您专门构建一个处理此问题的体系结构。

除此之外,只需让默认的应用程序错误处理程序处理该错误,因为无论如何它都是非常意外的。

If I cannot open the database I terminate the application - not much you can do without database access unless you specifically build an architecture that handles this.

Other than this, just let the default application error handler handle the error, since it would be pretty unexpected anyway.

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