怎么讲access数据库导入sql2005数据库啊

怎么讲access数据库导入sql2005数据库啊？谢谢各位大虾了 如果有教程更好！

sql2005不是有导入向导吗？按照步骤即可

安装好SQL Server 2005 Express后，再安装SQL Server Management Studio Express CTP就可以很方便的使用控制台进行数据库的管理。但SQL Server Management Studio Express CTP并没有导入Access数据库的功能，我们应该使用Access的“数据库实用工具”进行导入。本文以Access 2003为例介绍如何将Access的数据库导入到SQL Server 2005 Express中，其中没有说明的地方均使用默认设置。1、安装Access 2003，选中Access下的“数据库复制”组件。
2、打开Access 2003数据库，依次单击“工具”－“数据库实用工具”－“升迁向导”。
3、在“升迁向导”中选择“新建数据库”，单击“下一步”。选择安装了SQL Server 2005 Express的服务器为导入服务器，使用默认的数据库名称，单击“下一步”。将其中可以的表添加到“导出到 SQL Server”中，单击“下一步”。升迁默认的表属性，单击“下一步”。创建一个新的ADP文件，单击“下一步”。单击“打开新ADP文件”，单击“完成”。
4、打开刚刚创建的Adp文件，依次单击“工具”－“数据库实用工具”－“传送数据库”。在SQL Server中输入“server、sqlexpress”，（注意：一定要将服务器更改为“服务器名、sqlexpress”的格式，将顿号改成正斜杠，因为这里不能显示），单击“下一步”。单击“完成”。导入完成。
5、打开“SQL Server Management Studio Express”就可以看到刚刚添加的数据库。
刚刚安装的SQL Server 2005 Express，很多东西还没有开始研究。x

用opendatasource或openrowset后面跟个表名就是了比如 sheet1$. 2005下这两个默认是关闭的,需要设置打开.
各位在net中对依赖注入看法如何？在实际项目都有哪些体会呢？关注的框架都有哪些？都用着哪些容器

只因经常有人说做.net大都不了解依赖注入，我希望这个说法是错的。。

IoC还是依赖注入，都是为了满足面向对象设计的DIP，依赖注入所注入的对象通常是个可变因素
某客户类只依赖于服务类的一个接口，而不依赖于具体服务类，客户类只定义一个注入点。在程序运行过程中，客户类不直接实例化具体服务类实例，而是客户类的运行上下文环境或专门组件负责实例化服务类，然后将其注入到客户类中，保证客户类的正常运行。
感觉c#语言中的委托跟依赖注入有那么几分神似。

AOP纯粹是没事撑的。它是对设计模式的嘲讽，AOP发明者为了证明23个设计模式中有将近20个都是多余的，创建了AOP。这就好像用javascript来说明java、c#是多余的一样。
.net早就remoting中就有完善的对象注入和代理机制，任何人可以注入，但是微软也没有往这个上面宣传什么，因为remoting是为了实用才这样设计的，而不是玩什么AOP。
微软早在20年前就精通事件驱动编程，因为需要开创windows、控件编程的先河。可是也没有宣传什么AOP空洞思想。
编程这可靠地使用事件委托，使用INotifyPropertyChanged、INotifyPropertyChnaging、INotifyConnectChanged、DependencyProperty等等机制，只有我开放了那么客户端才能注入。
这就好像是：有拆箱装箱之说、有编程清晰性之说、有编译时检查bug之说，所以我们使用强类型编程。如果此时我们说：“既然有反射了，所以从此后不需要强类型编程，一切类型的数据都用字符串来搞什么‘动态编程’了！”，这不就是扯淡么？这种玩法可作为没事撑的研究性的编程风格，而不可能用来支持大规模的商用。
net设计师懂得具体问题使用委托，只有一个代码让别人插、定一个业务上明确的事件参数时才让你插，而不是你想破坏别人的代码就随便A了它说是“神似”实际上还是触动了我。依赖注入，这种“二倚子”看不清不难不女的技术不应该拿替代真正的好男人的技术。研究AOP，顶多是玩儿。你就搞清楚一件事就知道方便与危险的界限，是不是有了反射我们从此就不应该再用强类型的编程方式了？

sp1234说得好，：），不过对于AOP的是非当然是仁者见仁，反射不代表AOP，强类型也不定微软才有，它们更像是不同人对编程的理解，对于事物的好坏往往要从辨证的角度去评价

来源： nba直播