有图有真相,看看长啥样——喏,这就是数据连接属性对话框:
这个东东估计做过数据库的同志都见过,木啥希奇的,如果程序中需要用户输入一些数据库参数,用这个对话框当然是比较理想的,因为它的功能非常丰富和全面,基本上数据库连接方面的配置都能完成,很重要的是,还可以提供连接测试。俺现在要做的就是在程序中把它给调出来。环境是:C#。
把这个东东弄出来有两种基本思路,一种是调COM,一种是使用UDL文件,下面分别说一下。
调COM的思路是这样滴:
首先,在Solution Explorer视图中,展开目标工程,右键点击References,点击Add References...,在对话框中选择COM页,找到并选中下面两个选项:
Microsoft ActiveX Da
Microsoft OLE DB Service Component 1.0 Type Library
点击确定,这样,在References下面,应该就可以看到两个新的链接:ADODB和MCDASC,这就是我们将要使用的COM了。
然后,在需要使用数据连接属性对话框的地方,加入下面的代码:
MSDASC.DataLinks dlg = new MSDASC.DataLinks();
ADODB._Connection ADOcon;
//Cast the generic object that PromptNew returns to an ADODB._Connection.
ADOcon = (ADODB._Connection) mydlg.PromptNew();
非常简单,对吧,到这里这个数据库对象就得到了(不过还没有打开)。可以通过ADOcon.ConnectionString来取得连接字符串来进行后续的操作。
有些兄弟可能会有进一步的需求:希望对话框不是像本文开始给出的那幅图一样“啥都没有”,而是有一些缺省的设置,那么,我们可以把代码稍稍变化一下:
MSDASC.DataLinks dlg = new MSDASC.DataLinks();
ADODB.Connection ADOcon = new ADODB.Connection();
ADOcon.ConnectionString = "<缺省设置>";
if (dlg.PromptEdit(ADOcon)) {
//返回OK
}
也就是把缺省设置放在ADOcon对象的ConnectionString中传给对话框,这样,运行程序,你就会看到对话框中已经有了一些缺省的设置。
如果想部署到别人的机器上,则还需要确认一下这两个COM是否存在,其中MSDASC存在于Interop.MSDASC.dll,应该和编译生成的EXE文件在一起;而ADODB存在于ADODB.dll中,必需注册到GAC中才能使用。
相比之下,使用UDL文件的办法可以说是个笨办法,后面大家会看到,远远比上面用COM来的复杂;但笨办法也有笨办法的好处,那就是:它不需要那两个额外的DLL,特别是不需要注册ADODB.DLL这一点。不管怎么说,随随便便地在别人的机器里注册个东西总是不太符合绿色环保的精神,特别是对于那些像我一样并不打算真的使用ADO接口,而仅仅是使用这个类,然后取其中的连接字符串另作使用的兄弟来说就更是如此了。
好,言归正传,先说说UDL文件是什么。这东西是出人意料的简单,没见过的同志可以自己做个实验,在桌面(或者其他随便什么地方)上点击右键,创建一个文本文件,再点击右键,点击“重命名”,把这个文件的后缀由txt改成udl,然后你肯定就发现文件的图标变了(如果还是文本文件的样子的话,多半是系统设置中隐藏了文件的后缀,需要到控制面板中修改先),双击一下这个文件:咦,这不就是数据连接属性对话框了!——对,就这么简单。然后,你可以做一些自己需要的设置,完了点击确定,对话框关闭,这些设置就存在UDL文件里了。然后,你再用右键点击这个文件,点击Open with ...,选用写字板来打开它,就会发现里面现在保存着这样几行字:
[oledb]
; Everything after this line is an OLE DB initstring
Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=...;Da
其中第三行就是我们需要的连接字符串了,当然其具体内容会随着你的设置而有所变化。如果你再次双击打开这个文件,就会发现你上次输入的东西这次就作为缺省值显示出来了。
这样,我们就有了一个大致的思路:在使用COM的方法中,我们是使用ADODB的ConnectionString属性为媒介与对话框交互(既作输出结果传出生成的连接字符串,又可以作为输入参数传入缺省值)的话,那么使用UDL文件的时候,就是以UDL文件为媒体进行同样的操作。但实际编程的时候,还是有三个小窍门:
首先,这个方法需要生成一个临时的UDL文件。现如今Windows的权限控制也是越来越复杂了,生成在哪里稍微要费些思量,和程序放在一起当然是个办法,更“专业”一点的话,也可以考虑LocalApplicationData,它的位置随着Windows版本的不同而略有不同,这里就不展开了。
Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData)
其次,UDL文件必需以UNICODE格式保存(C#中缺省情况下以Utf-8格式保存文本文件)。
第三,如何在编程中打开UDL文件呢?我用的是System.Diagnostics.Process.Start("<UDL文件路径>"),试一下就知道,这个函数会创建一个新的进程来运行对话框,这样,在主进程与对话框之间就存在一个同步的问题,可以使用函数返回的System.Diagnostics.Process对象的WaitForExit()来等待对话框结束。
下面是我的代码,比使用COM的代码长多了,不过,好处就是上面说的,部署的时候不需要额外的DLL:
string connStr= "..."; //初始值
string pathUdl = Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData) + @"\test.udl";
//Create a udl file in app_da
TextWriter fsWrite = new StreamWriter(pathUdl, false, Encoding.Unicode);
fsWrite.WriteLine("[oledb]");
fsWrite.WriteLine("; Everything after this line is an OLE DB initstring");
fsWrite.WriteLine(connStr);
fsWrite.Close();
//Prompt the dialog
Process process = Process.Start(pathUdl);
process.WaitForExit();
//Read the result
TextReader fsRead = new StreamReader(pathUdl);
string tempStr;
while (true)
{
tempStr = fsRead.ReadLine();
if (tempStr == "" || tempStr[0] != ';' && tempStr[0] != '[')
{
connStr = tempStr;
break;
}
}
fsRead.Close();
//Clear the file.
File.Delete(pathUdl);
return connStr;
对于如果你把这个udl文件给封装起来了
就需要设置一个值来保存链接字符串是其他程序可以访问