[烛光生存狂]-业务OA平台的功能使用和二次开发总结

【6月23日】

第一个问题，关于主页面菜单项目增加和权限的问题。

首先，要使用在/rato/admintool/clearcache.aspx页面，清除菜单和权限缓存。

其次，在增加菜单是，要操作的表包括2个：BS_Menu表和BS_Function表。只有这两个表中对应项目都设置好之后才可以进行下面的操作。

第三，注意，在增加菜单后，即使是用管理员用户登录，主菜单下面的二级子菜单的链接也是看不到的，因为还没有按照用户或者角色分类，设置对应的权限。这样，就需要进到“系统管理”——“角色管理”模块中，选择对应的角色，再将对应角色需要增加的新权限（你看一下，现在新增加的菜单对应的功能模块前面的对勾是不是没有选中？

），前面打钩，保存一下，就可以看到每个模块对应菜单下面的二级子菜单也出来啦！

【6月24日】

1，从ERP里导出数据分析，其实不困难，首先很多模块都可提供导出为Excel表格的形式，导出后，将Excel数据表转为SQL Server数据库中的数据表，然后，在数据表中使用SQL语句查询，即可得出自己想要的结果，当然，如果您想将这个SQL语句保存下来，可以使用SQL Server提供的“视图”功能，保存自己想要的SQL查询过程，很方便的，以前一直以为“视图”是鸡肋，现在终于理解设计者的良苦用心了，不错不错。

今天做的是这样一个查询：首先根据2008和2009两年的业务记录明细，取出2008年和2009年的所有业务涉及的客户名称（简称），然后找出2008年的客户不在在2009年客户集合中的项目，然后再用客户简称作为连接字段，内联另外一个客户信息表，找到2009年丢失客户的联系方式等信息，一遍后续维护。

2，值得一提的是，在SQL Server2000下，用中文作为字段名称往往会出现错误，比如说上述查询，因为从Excel导入时Excel文件中是中文字段，然后导到SQL Server2000下也是中文，这样我那个查询结果为空，但是在导入前将Excel文件首列更改为全部都是英文的字段名，查询就可正常进行。

【6月24日回溯】

1，在增加记录信息中，原平台在“客户名称”或者“商品名称”字段中做过类似的设计，如果系统中存在类似信息名称，那么应该选择，而不应输入，否则会导致信息记录的重复。关于这个弹出窗口的设计，在系统中是有一个XML文件的，具体路径在：inc/XML/MultiRefTheme.xml 中修改。

【6月29日】

1，如果在企业管理器中，通过导出数据来导出一个表的内容和结构，往往在“表结构”的复制上面会出问题，比如说，int型的自增量设置，往往就会出现无法导出，出现默认值的情况，这样在修改后的数据表进行添加记录操作时就会出错。但是怎样用查询分析器导出表结构呢？这一点我以前试过，但是又没搞好，不得而知……

【7月16日】

终于返青了……再次开始……

1，有关当前登录用户的情况，显然是用COOKIE存储当前本机登录用户的用户ID的，不过它经过多次封装，从现有的模式来看，实际已经面目全非了。很简单的一个应用，比如说：

在很多表单中，当前登录用户的名字是作为默认的表单制作人而显示在文本框中的，在本业务平台中，我们只需插入下述代码（在aspx文件中）即可：

“

”

但是我经过测试以后，即使是把中间的那个多项选择弹窗MultiRef删掉后，还是可以在文本框中正常显示对应的当前用户名的，这个是什么问题？我们不得而知。

2，上文标签中所谓的cc1就是Assembly（自定义程序集）中的一个自定义控件。

【7月17日】

1，在每个aspx页面中所引用的CSS类（class)是在根目录的App_Themes文件夹中，比如说PF_Table类（早期的编辑表单）就在上述文件夹中的PF_Standard文件中可以找到，但是页面是如何和目录中的CSS文件建立链接的呢？还需要进一步考虑。

至于CSS，空格在CSS中有着特殊的含义，比如说我们在一个文件中定义一个TABLE的类TABLE.a,那么对应的TABLE的下级标签的自定义类即可写作：TABLE.a TD

2，有关文本框中输入的日期变量在aspx页面中显示格式不恰当的问题，这要分两个层面来考虑：

首先，存储日期的数据库字段（比如说W_PurDate）一定要设置为“日期/时间”类型，而不能是其它什么类型。

其次，SQL Server 2000数据库类型中只有一个范围扩大化的DateTime类型，也就是说它默认的不仅显示日期还显示时间，这也就造成了虽然通过页面输入的只有“年月日”（如2010-7-1）但是实际上存储的却是形如2010-7-1 00:00:00这样的格式，要把后面的时间量去掉，只有通过在保存表单对应项目的信息时进行修改。在本系统中既然以存储过程为核心，那么就要在SQL Server的存储过程中撰写，比如说我们可以这样写：

Select

...

,CONVERT(VARCHAR(10),W_PurDate,120) as W_PurDate1

From

...

当然，此项在数据列表页面中，对应的日期值应引用其别名，而不能引用原来的字段名（W_PurDate）。

当然，这又牵扯出另外一个问题，就是在某些模块中所使用的自定义控件“PagingList”，对应每个项目的排序属性（SortExpression)中，不能有在存储过程中没有涉及到的字段，否则系统就会报错。

【7月19日】

“牵一发而动全身”，今天在以前几天工作的基础上，把主要页面调好了，其实原来做好的各类自定义控件，都可以和普通控件一样用，比如说那个自定义的TextBox控件，同样可以设置其宽度和其它的应用属性，所以说，借口对自定义控件不熟，根本上还是对C#系统不太熟悉的缘故吧……

1，在工作平台中引用Calendar控件非常简单，因为系统已经定义好了一个比较方便的自定义对象了，我们可以在CHEN.XIN.Web.UI.Controls这个命名空间（程序集）中调用Calendar对象，然后主要设置TargetControlID属性为你要输入日期信息的目的文本框（比如说W_PurDate），但要注意里面的CSSClass属性，虽说在大多数时候页面只是一个辅助考虑到的因素，但是在这里，如果我们给这个控件的CSS类设置成不同于本Table（TD）中的类，那么打开的日历牌会变成透明背景的，很难看……

当然，我们用默认的PF_Table就不会有问题了，也就是说，日历牌中的每个Cell，对应的都是一个表格，所以在本容器（TABLE）中，对应TD的背景就是日历牌中Cell的背景，可是我又不想让表格中其它元素的背景像在日历牌中的那么醒目，那么我可以在对应的TD标签中，用Style重新设置背景色background-color（注意用HTML自带的属性是不行的，对于在CSS已经预定义的HTML标签属性，用HTML的自带属性是无法使其改变的）。而CSS在标签中的属性优先级要优于Class中的，所以用这个方法可以同时满足对表格和表格中日历牌的样式需求。

如果我们要设置某个表格边线为最细状态，只需要在CSS中写下这样的代码即可：

TABLE.PF_Table1

{

border-collapse:collapse;

border:none;

}

TABLE.PF_Table1 td

{

border:solid #4397c5 1px;

}

2，对于单选按钮Radio仍然没有掌握，不过在本次增加新模块的应用中，对于判断项的选择，倒是可以采用自定义程序集中的DropDownList控件，这个控件当然，如果要通过保存按钮作为存储过程的一个参数进行传递，也还是要使用CollectSign属性的，这点切记！！！

其他方面的使用就比较简单了，不过要记得，DropDownList中的ListItem却采用的是默认属性，其Tagprefix为“asp”。

【7.21】

1，在SHIBO的费用管理模块中有“发送短信”的功能，以前某些客户机总是无法顺利发送短信，总是提示“Premission Denied”的错误，经确认，应该是IE安全设置的问题，把IE中的“跨域浏览子框架”置为“启用”状态就可以了。

【9.1补充】

2，今天又有一台电脑出现了类似的问题，提示“拒绝访问”，然后我在安全设置中把“通过域访问数据资源”这项打钩，然后把IE浏览器的临时文件、历史文件和COOKIE都清空就可以啦。

另外，这个故障发生在通过外网IP访问的计算机上，“通过域访问数据资源”这个项目是否与其有关？应该进一步研究。

但是剩余可发送信息条数不准，需修改。

【7.24】

今天打开工作平台，外销的费用管理模块中所有的数据都看不到了，可是到数据库中，找到对应的数据表Ms_SaleBillList，却发现里面的数据是完全的，因为时间的关系，只能通过对数据库还原来解决。

有关数据库中的所谓“销售费用”信息，就是从ERP中的发票与发票明细表中所导出的，应该是调用了SQL Server 2000数据库中的一个所谓的“作业”来实现，每天中午12点自动从ERP的对应主表和明细表中导出到工作平台对应的主表与明细表中的。从对应的存储过程Ms_spSaleBillTrans中可以看出，如果某天导入失败的话，第二天也是可以正常导入昨天的数据的，因为它的where子句要求导入所有在工作平台中对应发票ID不存在的数值。

那个SQL Server 2000的“自动完成”功能，可在当前数据库的“管理”——>“SQL Server代理”——>“作业”中找到，在这里您可以进行作业的各种配置。

【2011.4.27】

今天遇到一个奇怪的问题，我用默认的系统管理员admin用户登陆，却总是提示“您的登陆尝试不成功，请重试”，我进入数据库的【Person】表，发现里面的“管理员”用户名和密码没有错误，而进入与之关联的【aspnet_Users】表，发现登陆ID也是原来的，但是为什么就出现问题了呢？不得而知

【2011.4.7】

有关“业务电话”模块的问题，进入每个电话分类列表里面，有个权限设置，今天点了个删除，结果这个分类就看不到了，实际上，可以到OA_BusiType中，将IsUsed字段改成“1”就可以了；在OA_BusiTel表中的电话簿记录应该也不会丢。

【2011.1.17】

今天又发现了一个问题，就是系统OA模块的“公告板”中，有一个应用组件功能，上传附件时，一点击上传，停了一会，然后出现错误提示：服务器Server State没有启动，请联系管理员！但是我查看服务器的状态服务，这个是打开状态的。查看代码，原来是ASP做的一个文件上传组件，代码中的逻辑是，只要有错误，就返回上述错误提示。因此实际上可能根本就不是状态服务的原因。我把服务器重启了一半，就好了，不知是什么问题……

【10月22日】

今天用户有反应订单信息（费用管理）找不到了，有些新客户无导入，按说已经解决了这个问题了啊，不应该存在数据未导入的问题，虽然最后证明是虚惊一场，但是有几点还是值得我们详细记录的。

首先是与 Ms_SaleBill 表对应的ERP中的 SaleBillVouch 表，大体上，不存在问题，但是有一点，就是在 Ms_SaleBill 表中，CurrencyRate（汇率）和TexRate（税率）字段用的是decimal型，而ERP中，iExchRate(汇率) 和 iTaxRate(税率)用的却是 float 型，按理说，decimal是一种精确表达的数据库类型，但是ERP中的字段用浮点类型，应该也自有他的道理，这点我们就不得而知了

【8月28日】

第一个问题：

平台又出故障了，这一次的问题仍然和以前一样，在内销模块的费用管理中，总是有部分销售发票记录无法在前台的列表页面正常显示，但是在数据库中查询对应表，记录却是有的，这是什么问题呢？

通过现象发掘事物的本质，是我们IT工作者必备的素质之一，因为本人并未参与此平台最初的研发工作，而且平台本身就存在很多根深蒂固的问题，比如说SP大量无节制使用，而又未能充分抽象化的现象，具体到本次遇到的这一故障，应该从何处入手呢？

1，首先对具体的记录进行分析，查看在工作平台对应的表 Ms_SaleBill 中，能在前台正常显示的记录每字段值和无法再前台正常显示的记录各字段值用表格的形式列出，仔细一对照，貌似看出一点端倪：有个 CusCode字段，显然是“客户编码”，可是客户编码按照常理应该是在另外一个客户表中，追根溯源，发现问题了，在本模块对应的客户表中，根本就没有对应上述未显示字段的客户编码！！！显然，这是系统再从ERP导入时出现了问题。

2，因为EPR功能模块的限制，关于费用回款以及短信通知等业务是于工作平台中开发的，因此在SQL Server作业中设置有自动导入发票费用信息和客户信息等功能，可是前段时间一执行自动导入，Ms_SaleBill表中就会有新增记录无法显示，这个问题困扰了我很久，但是并未采用科学的方法来逐步排除，这点应该引起我们的深思。

因为在费用列表中，我们显示的并非是客户编码，而是客户名称，显然要通过SQL语句的链接来连到 Customer表，但是【Ms_Customer】表中没有没有“客户名称”的值，自然就会产生可能的错误，而且在存储过程中又缺乏足够的容错性。

3，问题找到了，那么我手动执行从ERP导入平台的存储过程 Ms_SpCustomerTrans 应该就可以了吧？

可是问题并非如此简单！当我在查询分析器中执行 Ms_SpCustomerTrans 时，却出现错误提示：将截断字符串或二进制数据。,然后查看平台中的【Ms_Customer】表，记录仍然没有增加，还是1116条，而在ERP对应的数据表【Customer】中，却有1139条记录，这说明此存储过程的关键部分并未被执行，但是这个问题又出在哪里呢？

分析错误提示，会不会是数据库记录在从ERP导入专业平台的时候出现了数据溢出的错误，仔细查看【Ms_Customer】表和【Customer】表，在字段的对应上没有问题，可是在字段类型和分配空间上却有大问题！

第一，【Ms_Customer】表字段均采用varchar可变长字符串类型，而【Customer】表的对应字段均采用nvarchar非可变长字符串类型。

第二，两表对应字段项目所分配的字段大小也不一致，工作平台中的部分字段长度小于ERP对应表当中的。

首先更改工作平台表【Ms_Customer】中字段大小与ERP表中相同，可是问题仍然存在，但是将变长字符串类型更改为非可变长字符串类型，问题竟然解决了！至于二者的区别，应该回去继续研究。不过在以后执行数据库不同表的兼容性导入时，如果出现执行错误，不妨查看一下目的表的字段设计是否与源表兼容！

第二个问题：

对于发票费用来说，采用主从表的模式是自然而然的，因为必然涉及到发票明细的问题，但是这次另外一个问题正在从表上，在工作平台上【Ms_SaleBill】为主表，【Ms_SaleBillDetail】则为商品类别明细表，这两个表通过外键相连接，找到【Ms_SaleBillDetail】中对应的在前台消失的记录，竟然也存在！

显然，这里涉及到的不是客户编码，而是商品编码的问题了。

工作平台 ERP

Ms_InvType InventoryClass 商品类别表

Ms_Inv Inventory 商品表

而这里也存在前者在数据库设计方面未能充分兼容后者的问题，重新导入，运行，问题即解决了。

新用户注册返回首页
首页上一页下一页尾页页次1/1 转到第页