現(xiàn)在正做一個接口,通過不同的連接字符串操作不同的數(shù)據(jù)庫(數(shù)據(jù)庫培訓數(shù)據(jù)庫認證)。
專注于為中小企業(yè)提供網(wǎng)站建設、成都做網(wǎng)站服務,電腦端+手機端+微信端的三站合一,更高效的管理,為中小企業(yè)祿勸免費做網(wǎng)站提供優(yōu)質的服務。我們立足成都,凝聚了一批互聯(lián)網(wǎng)行業(yè)人才,有力地推動了上1000+企業(yè)的穩(wěn)健成長,幫助中小企業(yè)通過網(wǎng)站建設實現(xiàn)規(guī)模擴充和轉變。
要用到MySQL(MySQL認證Mysql培訓)數(shù)據(jù)庫,以前沒用過這個數(shù)據(jù)庫,用aC++(C++培訓)ess和sqlserver比較多。
通過網(wǎng)上的一些資料和自己的摸索,大致清楚了C++連接mysql的方法。
鹽城IT培訓認為可以通過2種方法實現(xiàn)。
第一種方法是利用ADO連接,第二種方法是利用mysql自己的api函數(shù)進行連接。
第一種方法可以實現(xiàn)我當前的需求,通過連接不同的字符串來連接不同的數(shù)據(jù)庫。
暫時只連接了mysql,sqlserver,oracle,access。
對于access,因為它創(chuàng)建表的SQL語句不太兼容標準SQL語句,需要做一些處理,這里暫時不說。
第二種方法只能針對于mysql數(shù)據(jù)庫的連接,不過用這種方法不用安裝MyODBC服務器程序。
不管用哪種方法,首先需要安裝Mysql數(shù)據(jù)庫,安裝方法請看“mysql安裝及一些注意點”。
最好安裝一個Navicatformysql,方便操作mysql數(shù)據(jù)庫。
下面分別說下這兩種方法:(一)通過ADO連接MySql數(shù)據(jù)庫1、通過ADO連接MySql數(shù)據(jù)庫,首先得安裝MyODBC服務器程序。
MyODBC版本要和MySql的版本對應上,否則會連接不上數(shù)據(jù)庫。
我用的版本分別是mysql-5.1.48-win32.msi和mysql-connector-odbc-5.1.5-win32.msi。
安裝好后,點擊開始菜單-設置-控制面板-管理工具-數(shù)據(jù)源(ODBC)-用戶DSN-添加-選擇MySQLODBC5.1Driver。
如下圖:然后雙擊MySQLODBC5.1Driver進行配置。
配置好可以點Test進行下測試(如下圖),如果能連上會彈出connectionsuccessful對話框。
MYSQL_OPT_READ_TIMEOUT 是 MySQL c api 客戶端中用來設置讀取超時時間的參數(shù)。在 MySQL 的官方文檔中,該參數(shù)的描述是這樣的:
MYSQL_OPT_READ_TIMEOUT (argument type: unsigned int *)The timeout in seconds for each attempt to read from the server. There are retries if necessary, so the total effective timeout value is three times the option value. You can set the value so that a lost connection can be detected earlier than the TCP/IPClose_Wait_Timeout value of 10 minutes.
也就是說在需要的時候,實際的超時時間會是設定值的 3 倍。但是實際測試后發(fā)現(xiàn)實際的超時時間和設置的超時時間一致。
而具體什么時候發(fā)生三倍超時,在文檔中沒有找到。所以對 MySQL 5.7.20 的源碼進行了一些分析。
使用 GDB 調試代碼找了實際與 mysql server 通信的代碼,如下:
其中 vio_read() 函數(shù)中,使用 recv 和 poll 來讀取報文和做讀取超時。net_should_retry() 函數(shù)只有在發(fā)生 EINTR 時才會返回 true。從這段代碼來看是符合測試結果的,并沒有對讀取進行三次重試。只有在讀取操作被系統(tǒng)中斷打斷時才會重試,但是這個重試并沒有次數(shù)限制。
從上面代碼的分析可以看出,代碼的邏輯和文檔的描述不符。于是在一頓搜索后,找到了一個 MySQL 的 BUG(Bug #31163)。該 BUG 報告了在?MySQL?5.0 中,MySQL c api 讀取的實際超時時間是設置的三倍,與現(xiàn)有文檔描述相符。于是對 MySQL 5.0.96 的代碼又進行分析。
同樣使用 GDB 找到了通信部分的代碼。這次找到了重試三次的代碼,如下:
這個版本的 MySQL api 的讀寫超時是直接使用的 setsockopt 設置的。第一次循環(huán),在 A 點發(fā)生了第一次超時(雖然注釋寫的非阻塞,但是客戶端的連接始終是阻塞模式的)。然后在 B 點將該 socket 設置為阻塞模式,C 點這里重置 retry 次數(shù)。由于設置了 alarm 第二次以后的循環(huán)會直接進入 D 點的這個分支,并且判斷循環(huán)次數(shù)。作為客戶端時net-retry_count 始終是 1,所以重試了兩次,共計進行了 3 次 vioread 后從 E 點退出函數(shù)。
由上面的分析可知,MySQL 文檔對于該參數(shù)的描述已經(jīng)過時,現(xiàn)在的 MYSQL_OPT_READ_TIMEOUT 并不會出現(xiàn)三倍超時的問題。而 Bug #31163 中的處理結果也是將文檔中該參數(shù)的描述更新為實際讀取超時時間是設定時間的三倍。也許是 MySQL 的維護者們在后續(xù)版本更新時忘記更新文檔吧。
1.連接數(shù)據(jù)庫:
SqlConnection cnn = new SqlConnection();//實例化一個連接
cnn.ConnectionString = "Data Source = datasource; uid = username; pwd =password; database = database_name";//設置連接字符串
cnn.Open();//打開數(shù)據(jù)庫連接
2.讓查詢在datagridview中顯示
SqlDataAdapter da = new SqlDataAdapter();//實例化sqldataadpter
SqlCommand cmd1 = new SqlCommand("select * from 表 , cnn);//sql語句
da.SelectCommand = cmd1;//設置為已實例化SqlDataAdapter的查詢命令
DataSet ds1 = new DataSet();//實例化dataset
da.Fill(ds1);//把數(shù)據(jù)填充到dataset
datagridview1.datasource = ds1.tables[0];//將數(shù)據(jù)集綁定datagridview,完成顯示
說明:dataset是一個數(shù)據(jù)庫在內存中的映像,包括數(shù)據(jù)庫中的表,視圖,關系等;sqldataadapter是C#的數(shù)據(jù)庫適配器,需要通過它來查詢數(shù)據(jù)庫,要通過SqlDataAdapter.SelectCommand來設置查詢語句,查詢后填充到dataset中,再把dataset和datagridview綁定就ok了,以上代碼寫在button事件中就可以。