數據鏈兼容性解決方法

⑴ 數據鏈連接電腦只充電，小米助手都顯示沒有和手機連接。

嗨！

建議你在電腦上安裝小米手機助手，來讓手機連接電腦。安裝成功後，會自動安裝驅動的。
小米手機助手，輕松實現以下功能：
1. 共享PC網路；
2. 安全備份；
3. 升級MIUI系統；
4. 下載游戲和應用。
安裝方法：下載安裝包到電腦端→運行→手機連至電腦→點擊開始安裝。
小米手機助手下載，http://zhushou.xiaomi.com/
使用方法http://www.miui.com/thread-1284064-1-1.html

（小米手機3和紅米手機在關於手機——android 版本——連續點擊7次手機就會進入開發者模式，然後手動重啟在設置里就可以看到開發者選項了 ，進去後打開或者關閉usb調試既可。）
無法連接電腦打開文件管理，建議您重新手動安裝驅動再試一下，如果還是不行，建議您可以嘗試換其他數據線或者電腦再試一下。
這是米1和1S驅動安裝方法：http://www.miui.com/thread-419692-1-1.html
這是米2系列（米2，米2a，米2s）驅動安裝方法：http://www.miui.com/thread-885876-1-1.html
您可以在設備管理器中手動安裝驅動。

下面的方法，請你逐步嘗試下：
1.請你查看下手機設置～開發人員選項～usb調試有沒有打開。
2.檢查下電腦驅動是否安裝成功，這是安裝驅動的鏈接，您可以參考一下：
米1/1S的http://bbs.xiaomi.cn/thread-504332-1-1.html
米2http://www.miui.com/a-104.html
3.如果你使用的是V5版本，你也可以在電腦上下載小米手機助手， 小米手機助手下載，http://zhushou.xiaomi.com/
使用方法http://www.miui.com/thread-1284064-1-1.html
（如果你需要安裝XIAOMI驅動，您可以下載小米手機助手安裝使用的，安裝完小米手機助手，會自動安裝驅動的）
4.或者 請您手動安裝小米手機驅動程序。
請你在這個頁面下載小米手機的驅動：
http://www.xiaomi.com/c/service/download/
在設備管理器中手動安裝驅動。
5.如果以上都不行，建議您更換一個數據線或者電腦試下。
【解決手機不能連接電腦的二種方法】
http://bbs.xiaomi.cn/thread-9012941-1-1.html

⑵ 在高強度電磁干擾環境下，怎樣保持數據鏈正常傳輸。

解決方法A：改變介質，說白了就是對方干擾我軍無線電我軍就改用電話線。
B: 只要傳輸信號足夠強，就不會被干擾了，加大傳輸設備的功率。
C：改變波段，比如敵軍干擾我軍長波通訊，我軍可以改用短波。
D：使用反輻射導彈幹掉對方的干擾設備。

⑶ oracle jdbc驅動包兼容性問題,我要同時連接oracle7和oracle10,有沒有通用的jdbc驅動包

1.最簡單的辦法，採用兩套鏈接。
因為，一個是7，每一個是10的話，你鏈接的應該是兩個資料庫實例。
那麼你可以寫一個類似於數據處理分發器的東西，通過一些類型判斷使用那個鏈接，但是從上層用戶角度看來，好像就是一個資料庫。
2.這個方法，就是，通過oracle之間建立數據鏈，這樣，你就可以相當於吧兩個資料庫的信息整合到一起，然後通過一個驅動鏈接

⑷ 數據鏈路層的三個基本問題(封裝成幀、透明傳輸和差錯檢測)為什麼都必須加以解決

因為這3項是數據鏈路層中所有的協議必須解決的問題，而且設計到安全問題。
數據鏈首先用於海軍戰術數據系統(NTDS)，它是第一代艦載或機載自動化通信系統,1961年研製成功。當時通過使作戰情報中心(CIC)計算機化來解決空戰難題。美國現役艦船約200艘裝備NTDS系統，其中包括航空母艦、巡洋艦、驅逐艦、護衛艦和兩棲攻擊艦。海軍戰術數據系統使用11號鏈、4號鏈和14號鏈。此外，在北約和美國海軍中還使用4A號鏈、16號鏈等。

⑸ 如何打破數據孤島難題

信息孤島，肯定是多套系統：得到困擾如下：

1、每套系統一個登陸地址、

2、要記住不同的賬號和密碼、

3、一個系統一個界面風格，操作習慣難統一

4、每一個系統都需要登陸一邊才知道有哪些需要單據審批和待辦

5、領導要知道公司整體生產，經營情況要到各系統查報表，費事費力

6、公司人員。制度和公共資料查找困難，

通過BPM敏捷開發平台，實現統一流程處理和業務邏輯處理，解決以下多套系統的問題

總上說述，打破孤島，還要從統一流程解決這個整體思路，結合系統部署的，和異構達到對應的訴求，完成對應的數據同步和結果。

存在即合理

⑹ 用數據結構鏈地址法解決沖突，編寫插入、刪除和查找演算法

多看看數據結構里的鏈接地址法的相關知識，像基本的插入刪除，查找都有講的。看一點樹，圖的知識。很久沒看書了，也忘記了，呵呵。書上有目錄的都有聯接地址發的敘述的。就是一般的數據結構的書都有吧。主要是在講二叉樹和圖的那些地方有這些存儲方法的數據結構。

⑺ Java 1.7 64位 連接資料庫兼容問題

可以試一下derby，他和slqite一樣小巧，不需要安裝，把JAR導入工程就可以了，優點是純java開發，缺點是沒有一個好用客戶端。
http://db.apache.org/derby/

mariadb在MySQL基礎上開發了，和MySql差不多
https://mariadb.org/

另外還有postgresql。
http://www.postgresql.org/

⑻ 除了差錯檢測外，面向字元的數據鏈路層協議還必須解決哪些特殊的問題

最主要的就是要解決幀定界和透明傳輸的問題。

幀定界就是要使接收端能夠知道一幀的開始和結束是在什麼地方。面向字元的數據傳輸就是所傳輸的數據全都是一個個的字元，例如ASCII字元。因此，在每一幀的開始和結束的地方，必須要有一個特殊的字元來作為標志，如下圖所示。

字元SOH代表StartOfHeader（首部開始），而EOT代表EndOfTransmission（傳輸結束）。請注意，SOH和EOT都是ASCII碼中的控制字元。SOH的十六進制編碼是01，而EOT的十六進制編碼是04。不要誤認為SOH是「S」「O」「H」三個字元，也不要誤認為EOT是「E」「O」「T」三個字元。

解決了幀定界後，在接收端就可以確定一個幀的開始和結束。剩下的問題就是透明傳輸的問題。

透明傳輸實際上就是隨便什麼字元都可以傳輸。但設想我們在幀中傳送的字元出現了一個控制字元「EOT」。那麼接收端收到這樣的數據後，就會將原來的SOH和數據中的「EOT」錯誤地解釋為一個幀，但對後面剩下的字元根本就無法解釋（見下圖）。

像這樣的傳輸顯然就不是「透明傳輸」，因為當遇到數據中的字元「EOT」就傳不過去了，它被接收端解釋為控制字元。實際上此處的字元「EOT」並非控制字元而是一般數據。

為了解決透明傳輸問題，就必須設法將數據中可能出現的控制字元「SOH」和「EOT」在接收端不解釋為控制字元。方法是：在數據中出現字元「SOH」或「EOT」時就將其轉換為另一個字元，而這個字元是不會被錯誤解釋的。但所有字元都有可能在數據中出現。於是就想出這樣的辦法：將數據中出現的字元「SOH」轉換為「ESC」「x」這樣兩個字元，將數據中出現的字元「EOT」轉換為「ESC」「y」這樣兩個字元。而當數據中出現了控制字元「ESC」時，就將其轉換為「ESC」「z」這樣兩個字元。這種轉換方法就能夠在接收端正確地還原為原來的數據。「ESC」是轉義符，它的十六進制編碼是1B。

下圖表示在數據中出現了四個控制字元「ESC」「EOT」「ESC」「SOH」。按以上規則轉換後的數據如下圖所示。

讀者可以很容易地看出，在接收端只要按照以上轉換規則進行相反的轉換，就能夠還原出原來的數據（例如遇到「ESC」「z」就還原為「ESC」）。

以上就是實現透明傳輸的原理。

⑼ 在數據鏈路層中,差錯控制的兩種基本方法是

差錯控制
用以使發送方確定接收方是否正確收到了由它發送的數據信息的方法稱為反饋差錯控制。通常採用反饋檢測和自動重發請求（ARQ）兩種基本方法實現。

反饋檢測法
反饋檢測法也稱回送校驗或「回聲」法，主要用於面向字元的非同步傳輸中，如終端與遠程計算機間的通信，這是一種無須使用任何特殊代碼的錯誤檢測法。雙方進行數據傳輸時，接收方將接收到的數據（可以是一個字元，也可以是一幀）重新發回發送方，由發送方檢查是否與原始數據完全相符。若不相符，則發送方發送一個控制字元（如DEL）通知接收方刪去出錯的數據，並重新發送該數據；若相符，則發送下一個數據。反饋檢測法原理簡單、實現容易，也有較高的可靠性，但是，每個數據均被傳輸兩次，信道利用率很低。一般，在面向字元的非同步傳輸中，信道效率並不是主要的，所以這種差錯控制方法仍被廣泛使用。

自動重發法
（ARQ法）：實用的差錯控制方法，應該既要傳輸可靠性高，又要信道利用率高。為此讓發送方將要發送的數據幀附加一定的冗餘檢錯碼一並發送，接收方則根據檢錯碼對數據幀進行錯誤檢測，若發現錯誤，就返回請求重發的答，發送方收到請求重發的應答後，便重新傳送該數據幀。這種差錯控制方法就稱為自動請求法(Automatic Repeat reQuest)，簡稱ARQ法。ARQ法僅返回很少的控制信息，便可有效地確認所發數據幀是否被正確接收。ARQ法有若干種實現方案，如空閑重發請求(Idle RQ)和連續重請求(Continuous RQ)是其中最基本的兩種方案。
空閑重發請求
(Idle RQ)：空閑重發請求方案也稱停等(stop-and -wait)法，該方案規定發送方每發送一幀後就要停下等待接收方的確認返回，僅當接收方確認正確接收後再繼續發送下一幀。空閑重發請求方案的實現過程如下： 發送方每次僅將當前信息幀作為待確認幀保留在緩沖存儲器中。當發送方開始發送信息幀時，隨即啟動計時器。 當接收方檢測到一個含有差錯的信息幀時，便舍棄該幀。當接收方收到無差錯的信息幀後，即向發送方返回一個確認幀。 若發送方在規定時間內未能收到確認幀(即計時器超時)，則應重發存於緩沖器中待確認信息幀。若發送方在規定時間內收到確認幀，即將計時器清零，繼而開始下一幀的發送。從以上過程可以看出，空閑RQ方案的收、發雙方僅須設置一個幀的緩沖存儲空間，便可有效地實現數據重發並保證收接收方接收數據不會重份。空閑RQ方案最主要的優點就是所需的緩沖存儲空間最小，因此在鏈路端使用簡單終端的環境中被廣泛採用。
連續重發請求
(Continuous RQ)：連續重發請求方案是指發送方可以連續發送一系列信息幀，即不用等前一幀被確認便可發送下一幀。這就需要一個較大的緩沖存儲空間（稱作重發表），用以存放
數據鏈路層圖3-2
數據鏈路層圖3-2
若干待確認的信息幀。每當發送站收到對某信息幀的確認幀後，便從重發表中將該信息幀刪除。所以，連續RQ方案的鏈路傳輸效率大大提高，但相應地需要更大的緩沖存儲空間。連續RQ方案的實現過程如下：發送方連續發送信息幀而不必等待確認幀的返回。發送方在重發表中保存所發送的每個幀的拷貝。重發表按先進先出(FIFO)隊列規則操作。接收方對每一個正確收到的信息幀返回一個確認幀。每一個確認幀包含一個唯一的序號，隨相應的確認幀返回。接收方保存一個接收次序表，它包含最後正確收到的信息幀的序號。當發送方收到相應信息幀的確認幀後，從重發表中刪除該信息幀。當發送方檢測出失序的確認幀(即第n號信息幀和第n+2號信息幀的確認幀已返回，而n+1號的確認幀未返回)後，便重發未被確認的信息幀。實際操作過程中，兩節點間採用雙工方式將確認幀插在雙方的發送信息幀中來傳送的。上面的連續RQ過程是假定在不發生傳輸差錯的情況下描述的。如果差錯出現，如何進一步處理可以有兩種策略，即Go-back-N和選擇重發。 Go-back-N是當接收方檢測出失序的信息幀後，要求發送方重發最後一個正確接收的信息幀之後的所有未被確認的幀，或者當發送方發送了n幀後，若發現該n幀的前一幀在計時器超時後仍未返回其確認信息，則該幀被判定為出錯或丟失。對接收方來說，因為這一幀出錯，就不能以正確的序號向它的高層遞交數據，對其後發送來的n幀也可能都不能接收而丟棄，因此，發送方發現這種情況，就不得不重新發送該出錯幀及其後的n幀，這就是Go-back-N(退回N)法名稱的由來。Co-back-N法操作過程如圖3-2所示。圖中假定發送完8號幀後，發現2號幀的確認返回在計時器超時後還未收到，則發送方只能退回從2號幀開始重發。Go-back-N可能將已正確傳送到目的方的幀再傳一遍，這顯然是一種浪費。另一種更好的策略是當接收方發現某幀出錯後，其後繼續送來的正確的幀雖然不能立即遞交給接收方的高層，但接收方仍可收下來，存放在一個緩沖區中，同時要求發送方重新傳送出錯的那一幀，一旦收到重新傳來的幀後，就可與原已存於緩沖區中的其餘幀一並按正確的順序遞交高層。這種方法稱為選擇重發(Selective repeat)，其工作過程如圖3-3所示。圖中2號幀的否認返回信息NAK2要求發送方選擇重發2號幀。顯然，選擇重發減少了浪費但要求接收方有足夠大的緩沖區容量。

⑽ 如何確保數據，信息的准確性，完整性，可靠性，及時性，安全性和保密性

數據完整性（Data Integrity）是

指數據的精確性（Accuracy） 和可靠性（Reliability）。它是應防止資料庫中存在不符合語義規定的數據和防止因錯誤信息的輸入輸出造成無效操作或錯誤信息而提出的。數據完整性分為四類：實體完整性（Entity Integrity）、域完整

性（Domain Integrity）、參照完整性（Referential Integrity）、用戶定義的完整性（User-definedIntegrity）。

保證數據的完整性:

1. 用約束而非商務規則強制數據完整性

如果你按照商務規則來處理需求，那麼你應當檢查商務層次/用戶界面：如果商務規則以後發生變化，那麼只需要進行更新即可。

假如需求源於維護數據完整性的需要，那麼在資料庫層面上需要施加限制條件。

如果你在數據層確實採用了約束，你要保證有辦法把更新不能通過約束檢查的原因採用用戶理解的語言通知用戶界面。除非你的欄位命名很冗長，否則欄位名本身還不夠。 — Lamont Adams

只要有可能，請採用資料庫系統實現數據的完整性。這不但包括通過標准化實現的完整性而且還包括數據的功能性。在寫數據的時候還可以增加觸發器來保證數據的正確性。不要依賴於商務層保證數據完整性；它不能保證表之間（外鍵）的完整性所以不能強加於其他完整性規則之上。

— Peter Ritchie

2. 分布式數據系統

對分布式系統而言，在你決定是否在各個站點復制所有數據還是把數據保存在一個地方之前應該估計一下未來5 年或者10 年的數據量。當你把數據傳送到其他站點的時候，最好在資料庫欄位中設置一些標記。在目的站點收到你的數據之後更新你的標記。為了進行這種數據傳輸，請寫下你自己的批處理或者調度程序以特定時間間隔運行而不要讓用戶在每天的工作後傳輸數據。本地拷貝你的維護數據，比如計算常數和利息率等，設置版本號保證數據在每個站點都完全一致。

— Suhair TechRepublic

3. 強制指示完整性

沒有好辦法能在有害數據進入資料庫之後消除它，所以你應該在它進入資料庫之前將其剔除。激活資料庫系統的指示完整性特性。這樣可以保持數據的清潔而能迫使開發人員投入更多的時間處理錯誤條件。

— kol

4. 關系

如果兩個實體之間存在多對一關系，而且還有可能轉化為多對多關系，那麼你最好一開始就設置成多對多關系。從現有的多對一關系轉變為多對多關系比一開始就是多對多關系要難得多。

— CS Data Architect

5. 採用視圖

為了在你的資料庫和你的應用程序代碼之間提供另一層抽象，你可以為你的應用程序建立專門的視圖而不必非要應用程序直接訪問數據表。這樣做還等於在處理資料庫變更時給你提供了更多的自由。

— Gay Howe

6. 給數據保有和恢復制定計劃

考慮數據保有策略並包含在設計過程中，預先設計你的數據恢復過程。採用可以發布給用戶/開發人員的數據字典實現方便的數據識別同時保證對數據源文檔化。編寫在線更新來「更新查詢」供以後萬一數據丟失可以重新處理更新。

— kol

7. 用存儲過程讓系統做重活

解決了許多麻煩來產生一個具有高度完整性的資料庫解決方案之後，我所在的團隊決定封裝一些關聯表的功能組，提供一整套常規的存儲過程來訪問各組以便加快速度和簡化客戶程序代碼的開發。在此期間，我們發現3GL 編碼器設置了所有可能的錯誤條件，比如以下所示：

SELECT Cnt = COUNT (*)

FROM [<Table>]

WHERE [<primary key column>] = <new value>

IF Cnt = 0

BEGIN

INSERT INTO [<Table>]

( [< primary key column>] )

VALUES ( <New value> )

ELSE

BEGIN

<indicate plication error>

而一個非3GL 編碼器是這樣做的：

INSERT INTO [<Table>]

( [< primary key column>] )

VALUES

( <New value> )

IF @@ERROR = 2627 -- Literal error code for Primary Key Constraint

BEGIN

<indicate plication error>

第2 個程序簡單多了，而且事實上，利用了我們給資料庫的功能。雖然我個人不喜歡使用嵌入文字（2627）。但是那樣可以很方便地用一點預先處理來代替。資料庫不只是一個存放數據的地方，它也是簡化編碼之地。

— a-smith

8. 使用查找

控制數據完整性的最佳方式就是限制用戶的選擇。只要有可能都應該提供給用戶一個清晰的價值列表供其選擇。這樣將減少鍵入代碼的錯誤和誤解同時提供數據的一致性。某些公共數據特別適合查找：國家代碼、狀態代碼等