Office中国论坛/Access中国论坛

标题: 关于vb6和access [打印本页]

作者: jsxfygq 时间: 2017-2-15 23:53
标题: 关于vb6和access
我有个朋友，用access+sql server给当地企业做信息管理系统，目前已经收入近百万，我问他既然用SQL数据库，为什么不换成vb6，做还部署也方便，功能也更强，他说offic现在电脑都有，部署没问题，而且vb6能实现的功能access都能做，且access更方便，不知道他对不对？

作者: roych 时间: 2017-2-16 11:43
VB6支持64位系统么？
——但是Access是没问题的。
不过，如果涉及到图形，COM，串口编程等，Access就很弱，甚至无法完成。

作者: 风中漫步 时间: 2017-2-16 12:45
acc做数据库很方便，看大家介绍也有很多不足
VB6已经不支持了，在64位机上应该也能跑，应该跑不好。主要是不支持了。

你那朋友在哪个城市做软件？

作者: zhengjialon 时间: 2017-2-16 14:27
一直在用ACCESS+sql开发，十几年了，合适的就是最好的

作者: jsxfygq 时间: 2017-2-16 16:12
楼上的兄弟，给个系统让我学习学习

作者: jsxfygq 时间: 2017-2-16 16:13

zhengjialon 发表于 2017-2-16 14:27
一直在用ACCESS sql开发，十几年了，合适的就是最好的

用这个组合的好处是什么？有没有遇到什么瓶颈？链接服务器数据库的连接信息怎么存放安全？

作者: tmtony 时间: 2017-2-16 16:36
Access行业源码
http://www.office-cn.net/forum-242-1.html
Access商业作品
http://www.office-cn.net/forum-236-1.html
http://access.office-cn.net/index.php/list/index/id/1.html

论坛里有很多相关行业的Access应用源码与示例，可以登录后搜索一下

前面回复你的都是Access的高手，使用Access为企业开发过很多真实的系统，可以向他们学习下

作者: jsxfygq 时间: 2017-2-16 16:48

tmtony 发表于 2017-2-16 16:36
Access行业源码
http://www.office-cn.net/forum-242-1.html
Access商业作品

后台是sql的吗？
光是access的话，我自己有能力做的，做过好多个了，谢谢兄弟。发现这个论坛的人很热心。

作者: jsxfygq 时间: 2017-2-17 14:07

风中漫步发表于 2017-2-16 12:45
acc做数据库很方便，看大家介绍也有很多不足
VB6已经不支持了，在64位机上应该也能跑，应该跑不好。主要是 ...

江苏南通

作者: jsxfygq 时间: 2017-2-17 14:08

roych 发表于 2017-2-16 11:43
VB6支持64位系统么？
——但是Access是没问题的。
不过，如果涉及到图形，COM，串口编程等，Access就很弱 ...

开发工具这块有没有更好的选择？

作者: roych 时间: 2017-2-17 15:54

jsxfygq 发表于 2017-2-17 14:08
开发工具这块有没有更好的选择？

看语言啊。你熟悉哪些语言就用什么开发工具咯。
例如，熟悉VB，可以用前面说的VB6或Access，也可以用VS的VB.Net（可以做B/S或者C/S）。
如果熟悉Java，当然可以用J2EE等等（C/S）。
甚至Delphi也可以很快开发，我们十七八年前，计算机双学位的毕业论文就是Delphi+SQL Server做一个软件。

作者: zhengjialon 时间: 2017-2-20 11:25
看看这篇文章：
http://www.office-cn.net/thread-122549-1-1.html

作者: ganlinlao 时间: 2017-2-25 12:53
提到一门语言，往往意味着提到的是它的编辑工具，意味着提到的是它的生态圈丰富不丰富。
我们很少会为一门语言能解决什么问题而感到欣喜若狂，更多的是为它不能解决哪些问题（缺乏什么特性）而感到纠结或痛苦万分。
提起一门语言常常充斥着宗教般的朝圣情怀，因为它甚至唤起我们对于某一段学习代码生涯的青春回忆或一段荡气回肠、爱恨交加的工作经历。写代码，已经交织进了我们生活的一部分。
哪怕我们曾经写过多么烂多么糟糕的代码，人们嘴上常说往事不堪回首，却在心里频频地回首，因为那么烂的代码也意味着我们蹀蹀撞撞人生的一部分。
SDK型的写代码者：一般SDK型是很少为哪一种语言感到纠结。他们往往执着甚至顽固于某种语言形式。一般某种语言推动者，都是这类人。他们象沉默的石头，但绝对有让人敬佩的高度。他们的狂热和深度会让你瞠目结舌。
工具型的写代码者：
寻找工具的写代码者：绝大多数业余的人，最纠结的是哪里去寻找适合的控件、类库。其实他很少在意语言能解决什么问题，在意的是控件够不够或正好适合我用的。如果不能，那就继续寻找。然后在这寻找的过程中，不停地痛骂自己喜欢语言有多少烂。

Access的好处，是它的边际很清晰，功能很单一。你不用太担心你必须学习太多知识，而能够解决日常百分之七八十的问题。

作者: jsxfygq 时间: 2017-2-25 17:02

ganlinlao 发表于 2017-2-25 12:53
提到一门语言，往往意味着提到的是它的编辑工具，意味着提到的是它的生态圈丰富不丰富。
我们很少会为一门 ...

剩下的30%呢，你怎么办？

作者: ganlinlao 时间: 2017-2-25 19:12
本帖最后由 ganlinlao 于 2017-2-25 19:21 编辑

剩下的30%，说实话，基本是跟语言无关，更多的是一些更基本的东西。
如下例子：
glew 2.0的VB6版本的DLL以及TLB制作过程
[attach]60824[/attach]

其中，glew32vb.dll是怎么制作的呢？
首先我发现VB6不能直接用glew32.dll是因为它用函数指针记录opengl特性函数的地址，导出dll时直接导出这个函数指针的符号，VB6是不能直接调用DLL里面的函数指针指向的函数的。这些函数都是由驱动提供，glew在Windows下都是通过调用wglGetProcAddress取得的，因此glew32.dll不能直接静态地导出这些函数的地址。
怎么办呢，我的做法是直接写个汇编的跳转表，自己导出这些函数的符号，当VB6调用我的汇编写的DLL导出的符号的时候，我一个jmp就能直接跳到函数指针指向的函数的入口处。这样我既有静态的导出函数的地址，又能帮VB跳到函数指针的位置。
OpenGL支持的函数很多，如果要手动写这个汇编的话，效率非常低。这肯定要自动化的，也不难，直接用exescope看glew32.dll的导出表，然后把它存储为txt，就能得到这些符号了。
exescope导出的txt非常整齐，直接用notepad++打开，Alt+左键，一个列编辑操作，直接就可以把左边两列没用的东西都删了，得到纯粹的符号表。
……
……
……
其中我在调试的过程中发现了用MIDL生成TLB的一些特性：
1、MIDL不支持函数指针。
2、所有的typedef都必须写在module的前面。
3、VB6不认char*, 各种**, 各种int, unsigned long, unsigned short, signed char等各种类型。
为了解决这些特性，我的这个工程具有以下功能：
1、两遍pass，把typedef和常量、函数分开。
2、避开重复定义，遇到重复定义的常量，直接注释掉。
3、遇到定义常量别名的情况：自动将第一次pass时记录的常量值展开。
4、遇到函数的参数列表里有函数指针时：强行换成void*
5、遇到char*时：强行换成LPSTR
另外我手动把那些和VB6无关的玩意儿，比如安卓的EGL、Unix的GLX等特性文件，都移到了别的文件夹。

****************************
这就是关于30%的部分。
坦白地说，要看懂上面的所有内容是极其不容易的。

作者: ganlinlao 时间: 2017-2-25 20:17
本帖最后由 ganlinlao 于 2017-2-25 20:42 编辑

造轮子的悲哀
在学习代码的过程中，你一定听到过无数次这样的话“不要重复去造轮子”或“我只是业余者，没必要学那么多”。
在实际中，我们悲哀的是，我们没有重复去造轮子，而是轮子出问题了，我们没办法修复或没能力修复。
我们努力想充当业余者，却不知不觉也学了那么多。而且有些时候，是因为我们感到愤怒，而不知不觉学了那么多。
比如我们会愤怒微软的fso，dictionary,Reg等已经二十年了，一点变化都没有，而不知不觉想去寻找更好的替代类库。
json类库，minixml类库，更强功能的集合类，哈希表，链表……
幸运的事，在别的语言中实现的好用的类库，基本上能在另一种语言比较容易获得相应的类库，只不过我们需要一点耐心。

作者: ganlinlao 时间: 2017-2-25 22:10
本帖最后由 ganlinlao 于 2017-2-25 22:15 编辑

“低耦合高内聚”的嬗变
一般我听到有人面红耳赤，声嘶力竭地说，vba不是面向对象的语言，vb6早该扫进坟墓里。我都会默默地走开。
“低耦合高内聚”是我们在学习类时，不停地会听到的经典原则。VBA本身不支持继承的代码实现，这是一种遗憾，但却不难理解。但继承和指针一样，一旦滥用，绝对也是一场灾难，继承，一定是高耦合。com本身是跨语言，你没办法让vb继承vc++的类，也没办法让vb继承delphi或python的类，因为继承是编译器的功能，同样的，你也无法让c#继承java的类一样。所以vba不支持继承不难理解，不支持继承不意味vba失去什么。
vba支持接口，而接口本身就是一种解耦，即使到现在不管是c#或vb.net，你听到的一定是少用继承多用接口。
其实c/s向b/s的转变，本身也是一种代码的解耦。b/s的服务端代码，耦合性更低。
只不过b/s本身也不是万能的方式，因为一个很明显的讽刺的事实是，不管是写asp.net，php，jsp……的代码编辑器都是桌面软件，大多是通过c/s方式进行代码管理（不管是托管github或哪里）。我见过的几十种的代码编辑器本身都是桌面型工具，为什么它们不选择网页方式？

作者: jsxfygq 时间: 2017-2-26 19:57

ganlinlao 发表于 2017-2-25 22:10
“低耦合高内聚”的嬗变
一般我听到有人面红耳赤，声嘶力竭地说，vba不是面向对象的语言，vb6早该扫进坟 ...

你的话说有高深

作者: jsxfygq 时间: 2017-3-1 21:52

ganlinlao 发表于 2017-2-25 22:10
“低耦合高内聚”的嬗变
一般我听到有人面红耳赤，声嘶力竭地说，vba不是面向对象的语言，vb6早该扫进坟 ...

这是access论坛。

欢迎光临 Office中国论坛/Access中国论坛 (http://www.office-cn.net/)