数据链兼容性解决方法

⑴ 数据链连接电脑只充电，小米助手都显示没有和手机连接。

嗨！

建议你在电脑上安装小米手机助手，来让手机连接电脑。安装成功后，会自动安装驱动的。
小米手机助手，轻松实现以下功能：
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. 使用查找

控制数据完整性的最佳方式就是限制用户的选择。只要有可能都应该提供给用户一个清晰的价值列表供其选择。这样将减少键入代码的错误和误解同时提供数据的一致性。某些公共数据特别适合查找：国家代码、状态代码等