商云方的技术博客 (沪ICP备14046774号-1)

 

Creation date: 2008-02-28
lastupdate_date: 2008-04-20

 

目录

1、客户端如何做SQL Trace
2、服务端如何做SQL Trace
3、ProposManager 在执行每日更新档案+单据的时候，Sql逻辑是怎样的
4、门店通讯对数据库的压力测试
5、门店转货单的转入特殊检查逻辑是怎样的
6、门店端通讯问题及处理
7、门店通讯数据的自动发布（给门店）工作原理
8、如果需要新增一种业务单据发布配置，有什么要求
9、Windows2000 Server 上配置通讯服务器：配置类型不正确的问题
10、POS门店终端系统对营业日期的控制原理是怎样的
11、POS门店库存现有量在线查询的实现原理是怎样的
12、POS后台的自动发布程序，每运行一次都会产生一个空Public包，让所有门店下载，能否禁止此包的生成?
13、POS门店的会员功能对POS终端系统做了哪些改变
14、基础数据不能发布的问题
15、基础数据重新初始化的方法
16、如何给门店广播SQL语句，让所有门店执行?
17、门店终端的店铺铺货收货查询的SQL是怎门拼出来的?
18、为什么有些门店把加价额的乘法系数理解为加法?
19、通讯过程中发布到门店的数据丢失怎么办？
20、通讯服务器的分工是如何进行的？
21、POS终端是如何与Sqlserver数据库联接的？
22、POS终端是如何加载菜单的？
23、POS终端的每个Form是否有统一的入口函数？

 

1、客户端如何做SQL Trace

在POS客户端安装Sql server 2000 客户端以后，有个事件探查器，打开它。

打开后，在服务器中输入 服务器名(可以在windows 右下角的Sqlserer服务器图表上击右健，选择“打开Sql server 服务管理器，即可看到服务器名)

验证方式选择windows验证， 然后点[开始]即可开始Sql trace .

执行POS客户端的一个动作，只要与数据库有关，其Sql语句即可在事件探查器中找到，此举可以查看客户端的Sql逻辑。

 

2、服务端如何做SQL Trace

要想了解 POS后台发布程序: ProposManager 的sql逻辑，可以使用Plsql developer (APPS登陆) 看session , 运行ProposManager中的某个动作，然后看Sessions 可以看到有几个Session 是来自发布程序的。可以查看其执行的Sql

 

3、ProposManager 在执行每日更新档案+单据的时候，Sql逻辑是怎样的

哪些单据，在满足哪些条件的情况下需要被导出，请看配置表：XYDATAINTERFACE

SELECT * FROM XYDATAINTERFACE

实例：曾经有一次，对退货申请做了审批后(把zbstate 改成03)，执行”ProposManager -执行每日更新档案+单据” , 通讯后按POS终端的退货申请单的表体丢失（原来是有的）,查下载的压缩包，发现包中有表头而无表体。再查后台数据库，表体未丢失。所以肯定是ProposManager 导出时未将表体导出，而终端导入单据时对相同单据号的单据采取了简单的覆盖；因为下载包中表体丢失，所以覆盖后终端的表中表体也丢失了。查表XYDATAINTERFACE

SELECT * FROM XYDATAINTERFACE WHERE MODULECODE = ‘OUTGOODS01’ 发现其配置的表体错误：DETAILTB 字段的内容是：OUTSTORAGESTMX 应该是OUTSTORAGEST

进行更改：

UPDATE XYDATAINTERFACE SET DETAILTB =’OUTSTORAGEST’,RELATIONSCRIPT =’OUTSTORAGEHEAD.OUTSTORAGEFORMHEADID=OUTSTORAGEST.OUTSTORAGEFORMHEADID’ WHERE MODULECODE = ‘OUTGOODS01’

再更改后台退货申请单为未导出状态:

UPDATE OUTSTORAGEHEAD SET SENDDATA =’N’, ALREADYSEND=’N’ WHERE OUTSTORAGEFORMHEADID = ‘OBBJT001080207002’

更改后再次执行” ProposManager -执行每日更新档案+单据” ,退货申请单的表头表体被成功导出。

 

4、如何做门店通讯对数据库的压力测试

同时打开两个门店的通讯，查看通讯服务器: 创建了两个可执行线程。有两个门店在线。查看数据库的Session ,高峰时刻创建了8个Session; 每个门店4个session ; 其中3个文件传输服务的Session. 1个数据导入session;

数据导入session 是在完成后立即消失的。文件传输的session在完成通讯后1分钟消失。

分析：

1 当前的通讯技术体系在多店并发通讯的时候会对数据库形成大量的session.

2 文件传输服务 的session 主要执行如下操作：
     2.1 查询 UserCenter 表 (判断门店是否为注册门店)
     2.2 如果有数据包上载，则往RecvFileMsg 表中插入一条记录，记录包名等信息。
     2.3 如果有数据包下传, 下传后更改SendFileMsg表中数据包的发送状态。

3 数据导入服务
     3.1 根据RecvFileMsg 表得知需要导入哪些数据包；涉及的表操作及数据量决定于门店的业务量。

 

5、门店转货单的转入特殊检查逻辑是怎样的

本人POS终端在做门店转入时, 系统提示无法取得合法会计期；转入失败；

起用Sql 事件探查器，得到检查的sql逻辑：

select AccountantCycID from AccountantCyc where BeginDate<=”2008-02-08” and endDate>=”2008-02-08”

原因是POS终端的 AccountantCyc 表中没有2008-02的会计期。看来POS终端对会计期有依赖。至少检查逻辑有一定的依赖。

在终端sql server上 执行：select * from AccountantCyc 发现没有记录,我的转入门店是BJXXX

解决方法：查POS后台数据库，select * from AccountantCyc发现 有记录，而且已经到了2008-12;

查后台基础数据发布配置： SELECT * FROM POSSENDTABLERST 发现AccountantCyc属于 公用基础档案 -ARCHIVES04; 使用Proposmanage 右边选择用户”BJXXX@XX天地(DNN) , 左边树中选择：” ARCHIVES04” ,然后开始发布。然后在门店做数据通讯 , 这下AccountantCyc的记录就过来了。再执行转入就成功了。

 

6、门店端通讯问题及处理

一、用户验证太慢的原因

我在执行门店通讯时，发现某个门店的用户验证过程太慢，而另一家门店则比较快。比较后台数据库中Usercenter 中两门店的注册记录，发现比较慢的门店的ServerAddr 字段，即通讯服务器的IP地址有误。更正后即快了。奇怪的是 如果注册在Usercenter中的ServerAddr错误也能正确通讯，只是验证慢了点，估计是程序中有判断，如果注册的通讯服务器联系不上，则使用默认的通讯服务器。

二、用户名/密码错

门店通讯时，用户名和密码的验证逻辑是这样的：

1、 POS终端从Sql server数据库中的usercenter表中取出用户名(门店ID) 和密码; 发送到通讯服务器，通讯服务器连接POS后台数据库，到后台数据库的usercenter表中进行比较。注意这里只比较用户名(门店ID) 和密码; 跟Hardid 和注册码没有关系。

三、通讯服务器报”HIDECONTENT” 无效标识的错误。

1、请检查 XYTRANSFERSERVERLIST 的配置是否正确。

2、目前发现产生这种错误的另一种规律是：每次连接新安装的通讯服务器器会产生这种问题。

HIDECONTENT 是 只在 SENDMAILMSG 和 RECVMAILMSG表中存在的字段。

但出现此错误的门店数据库及后台数据库中这两张表均无任何数据，HIDECONTENT也都是有的。

分析：现象1：有的门店可以连上来，由的门店不能连，出现 ”HIDECONTENT” 无效标识错误。 看FileTransServer 的Seesion 中执行的Sql语句：select SendFileMsg.*, SendFileMsg.ROWID from SendFileMsg where UserID=’BJT001′ and (SendSign=’N’ or SendSign is null) order by Operationtime；是要到SendFileMsg表中去找数据包，不过由于我们更换了通讯服务器，SendFileMsg表中有很多记录是记录了其他通讯服务器的数据包的历史数据。把这些记录全部删除，终端再次连接，发现错误依旧。

再次看SendFileMsg表又有了很多记录，觉得不正常，因为删除sendfilemsg表后没有人发布什么基础数据，也没有人操作业务，所以应该没有记录才对，再次跟踪FileTransServer 的Seesion，发现执行了如下语句：Insert into SendFileMsg(FileNo, FileTypeID, FilePath, OperationTime, ZipFlag,UserID,Title) Select FileNo, FileTypeID, FilePath,OperationTime,ZipFlag,’BJT001′,’SQL语句包’ from SendPublicFile where UserTypeID=’02’ and FileTypeID like ‘02%’ and OperationTime>= To_date(‘2008-02-06′,’yyyy-mm-dd’) and OperationTime>(select InitDatetime from Usercenter where UserID=’BJT001′) and FileNo not in (Select FileNo from SendFileMsg where UserID=’BJT001′) ，也就是说FileTransServer 在接到某个门店的通讯请求后，首先从SendPublicFile 中把该门店的public发布记录插入到SendFileMsg表，由于SendPublicFile中原来也有很多历史记录（包括老通讯服务器的记录），所以导致SendFileMsg依然会有很多历史记录（通讯服务器的地址不对）

把SendPublicFile 和 SendFileMsg表中的记录删除，终端再次连接新安装的通讯服务器就可以了。

问题：产生此问题的更细节的原因是什么？如果要更改通讯服务器，又不想让门店产生类似错误，又不想去删除SendfileMsg 和 SendPublicFile 表中的历史记录，该如何处理，请提供文档。

仔细查看SendPublicFile记录的数据包，发现这写数据包打开后里面的内容均是： <SQL DATABASENO=1 RECORDCOUNT=0> </SQL> ; 实际也没啥内容。

进一步研究发现，SendPublicFile 中的每个数据包均会在SendfileMsg表中重复N次，这里N=usercenter表中的有效门店注册记录数(那种hardid，registercode没有值的记录视为无效) ; 这表明SendPublicFile 中的每个数据包会传给所有门店，可以利用此功能让所有门店执行某些Sql语句。

那么 SendPublicFile 是怎样产生的呢？

四、门店初始化时，导入基础档案时报公司档案的公司ID主键约束违反错误。

分析：公司ID 在 公司档案表中，无论在后台还是终端都是主键，理论上不存在重复的可能，不过后来发现是后台表中有两条记录比较怪异，公司ID字段有特殊字符。可能的解释是：由于含有特殊字符，虽然在后台数据库中的内容是不一样的，不违反主键约束,但是导出到文本文件后，特殊字符均被当做?处理，这就有可能产生重复的公司ID了

 

7、门店通讯数据的自动发布（给门店）工作原理

我们已经知道单据的手动发布是通过PorPosmanager的每日单据发布进行的。那么自动周期的发布如何实现的呢？

既然PorPosmanager的每日单据发布已经完成了单据发布的功能，那么自动发布理论是只依赖于PorPosmanager所调用的COM+组件，而这个组件估计是ServerDataExport.dll;

那么现有的Pos系统有谁可以做到周期的运作某个任务呢？ 从后台数据库的Session看，最有可能的就是PMyjobsvr.exe; 这是一个Windows 服务，从session的sql 看，它访问了myjob这张表，仔细研究这张表发现其APPPATH字段存储了COM+的对象名称，测试环境的所有myjob记录的APPPATH都是 INTERFACESERVICE.EXPORTINTERFACE ，这个组件是在安装了Pos Web应用以后才在COM+组件服务中看到的，进一步查看可以知道其对应的DLL是 C:\WEBSYS\DLLOBJECT\AspObject\InterFaceService.dll ；再看其OTHERPARAMVALUES字段，存储了“67/INTERFACE1”这样格式的数据，结合学位研究的 exportmain,exportcontent 两张表的表结构，可以判定：67实际上就是exportmain 的projectid 字段。其后台程序正是通过这个关联来建立Job 与接口配置表之间的联系的。

在安装PMyjobsvr.exe（一个windows服务，服务名为：DrpJobSvr）后，启动该服务，发现 DrpJobSvr为每条STARTSIGN=’Y’的记录建立了一个Session, 然后每隔Session会定期更新Myjob表，更新周期即Myjob表中的DelayMinutes 字段的分钟数。这说明安装的服务是在起到一个周期调用某个程序的作用，有点类似于ERP的并发管理器。而Myjob表中的每条记录类似于ERP的每个并发程序。但可惜的是，在我的测试环境每个Job的运行结果均是“运行失败！Type mismatch” 目前暂不清楚这个错误是DLL应用层的程序调用错误还是数据库动态SQL错误。

上述分析可以解释POS<->ERP之间的自动接口导入导出工作原理，但是无法解释单据自动Export到Zip文件（供门店下载）的工作是如何进行的，因为测试的接口配置表（exportmain），全部是有关POS<->ERP的配置信息。从这个方向入手是无法得出结果的。我想，是不是可以利用PMyjobsvr.exe来调用ServerDataExport.dll的功能？ 于是更改了myjob表中的一条记录，更改其APPPATH为：SVRDATAEXPORT.OBJEXPORTDATA， 然后重新启动DrpJobSvr 服务，结果令人失望，DrpJobSvr虽然为这条STARTSIGN=’Y’的记录建立了一个Session,但是却没有任何动作。也即是说没有周期的运行某个Job; 查看PMyjobSvr.exe 所在目录的Job任务操作日志.txt ，发现错误日志为：“Method ‘JobRun0’ not supported by automation object” 分析为：PMyjobSvr.exe 期望SVRDATAEXPORT.OBJEXPORTDATA 中有个方法JobRun0，但是其中却没有，所以失败。按照这个思路，去找还有什么DLL中有JobRun0? 发现同在PMyjobSvr.exe 所在目录下的 ProJobCom.dll 在注册为COM+ 组件后，其中有个JobRun0方法，于是就尝试在 Myjob表的APPPATH中填写这个对象: PROJOBCOM.COJOBTEST ; 而OTHERPARAMVALUES 字段中不知道应该填写什么东西(因为COM+组件浏览器中看不到方法所期望的参数) , 于是就随便填写为” 200/INTERFACE1” , 这么更新后重新启动 DrpJobSvr服务； 奇迹发生了，我们的单据发布为Zip包成功了。而且这个job 周期运行也很正常，估计是 ProJobCom.dll 调用了 SvrDataExport.dll , 单据发布的配置表应该跟ProposManager 发布单据所用的配置表是同一张表，即： XYDATAINTERFACE

总结： 单据自动发布（给门店）的安装配置方法：

1、 把”DRPJob任务管理服务” 目录拷贝到接口服务器的某一个目录(如：D:\SystemConfig\ ERP接口服务程序)

2、 在MTS 中注册组件ProJobCom.dll

3、 在 开始 ――> 运行 输入 D:\SystemConfig\ ERP接口服务程序\PmyJobSvr.exe –install 注册服务

4、 修改连接字符串配制文件connection.Ini

5、修改表MyJob连接字符串字段内容,增加一条JOB配置：

INSERT INTO MYJOB

(JOBCODE, JOBNAME, BUILDDATE, APPPATH, OTHERPARAMVALUES, REMARK,

DAYRUNTIME, DAYENDTIME, DELAYMINUTES, LASTRUNTIME, NEXTRUNTIME, RUNNOTE,

INTERFACENO, CONNECTIONSTR, CONNECTIONSYSSTR)

VALUES

(‘JB80’, ‘门店单据发布’, SYSDATE, ‘PROJOBCOM.COJOBTEST’, ‘200/INTERFACE1’,

‘单据’, ’04:01:01′, ’23:59:59′, 5, SYSDATE, SYSDATE, ‘ ‘, 0,

‘PROVIDER=MSDAORA.1;USER ID=DPFCPOS;PASSWORD=DPFCPOS;DATA SOURCE=POSUAT;PERSIST SECURITY INFO=FALSE’,

‘PROVIDER=MSDAORA.1;USER ID=DPFCPOS;PASSWORD=DPFCPOS;DATA SOURCE=POSUAT;PERSIST SECURITY INFO=FALSE’);

备注： 基础数据的自动发布实际上也是这个JOB; 也就是说这个JOB自动完成基础数据和业务单据的发布。基础数据配置表POSSENDTABLERST 中的sendsql 是job选择数据时使用的sql ; sendsqlsign是让job决定是否要发布此基础数据的标记。； 业务单据配置表xyinterface中的filtersql是job选择数据时使用的Where条件，sendtag是让job决定是否要发布此业务单据。

利用 proposmanager.exe发布基础数据时，POSSENDTABLERST表中的sqltext,initsqltext对发布不产生任何影响(这些sql中的where条件对手工发布基础数据不起过滤作用) 。proposmanager.exe似乎在程序中写死了基础数据发布的SQL .

利用 proposmanager.exe 进行每日业务单据发布时，界面上的可选参数不起作用，这个动作会对xyinterface中配置的所有单据进行发布。

 

8、如果需要新增一种业务单据发布配置，有什么要求

答：在xyinterface中增加业务单据发布配置。必须有main表和Detail表；缺一不可，业务单据表必须包含一些默认的字段，senddata, aleradysend, fileno 等。Xyinterface 只适用于 一对一的master-detail结构。对于一对多的master-detail （比如变价单，主表： SPRDISCOUNTORDEP，子表1：SPRDISCOUNTORDEPST，子表2：SPRDSHOPPELIST）原供应商是放在POSSENDTABLERST表中的。

 

9、Windows2000 Server 上配置通讯服务器：配置类型不正确的问题

现象：1 在启动组建服务的时候报如下错误：

现象2 Job 管理器日志也报类似的错误:

解决方法：

原因：远程登陆用户不是交互式用户，在标识中更改为特定帐户即可。

 

 

10、POS门店终端系统对营业日期的控制原理是怎样的？

答： 在终端的MSDE数据库中有张表shoppedayovertb纪录了当前营业日期。

当POS终端登陆的时候:
1）若windows系统日期<当前营业日期,则提示“系统日期小于最后一个营业日期，不允许登陆”
2) 若windows系统日期>当前营业日期,则提示“上个营业日期尚未日结，必须先做日结后才能登陆“

这两个条件限制了POS终端只能在windows系统日期= shoppedayovertb表中纪录了”当前营业日期”的时候，才能进系统进行业务操作。

如果处于测试目的，非要进POS终端模拟某个历史日期的业务操作,那么可以在POS终端数据库运行如下语句强行更改POS终端的” 当前营业日期” : update shoppedayovertb set usedate = ‘2007-03-12 00:00:00.000’Where ShoppeID=’BJ311’;

 

11、POS门店库存现有量在线查询的实现原理是怎样的

答，在POS门店的终端系统，进入库存在线查询，可以立即查询到后台的库存。其实现原理是，由门店终端组织一条查询Sql语句，语句类似：

SELECT S.SHOPPEID, S.SHOPPEBENELUX AS SHOPPENAME, C.PRODUCTID,

SUM(C.STORAGEEXISTQUANTITY) AS STORAGEEXISTQUANTITY

FROM EMITPDTOPTSTGDESKACCOUNTGA C

JOIN SHOPPEDOSSIER S ON (C.SHOPPEID = S.SHOPPEID)

WHERE ACCOUNTYEARMONTH = (SELECT MAX(CURRENTACCOUNTANTCYCID)

FROM COMPANYCARRYSTATE)

AND S.SHOPPEID = ‘BJ367’

and S.SquareCompanyID not in (select UserID

from RecvFileMsg

where Restoresign = ‘N’)

and S.SquareCompanyID not in

(select Sink

from ActionSeries

join View_ActionSeries on ActionSeries.ActionID =

View_ActionSeries.ActionID)

GROUP BY S.SHOPPEID, S.SHOPPEBENELUX, C.PRODUCTID

将该语句压缩成zip包，通过通讯方式发往通讯服务器，通讯服务器收到包后交给导入程序，导入程序执行SQL,并把Sql结果打包，通过通讯传回门店终端。整个过程式连续的，门店处在在线等待整个过程执行完毕。所以感觉是”On-line”的。

 

12、POS后台的自动发布程序，每运行一次都会产生一个Public包，让所有门店下载，而这些包中其实是一条空的SQL语句，没有什么意义，能否禁止此包的生成?

答：仔细查看SendPublicFile记录的数据包，发现这写数据包打开后里面的内容均是： <SQL DATABASENO=1 RECORDCOUNT=0> </SQL> ; 实际也没啥内容。

进一步研究发现，SendPublicFile 中的每个数据包均会在SendfileMsg表中重复N次，这里N=usercenter表中的有效门店注册记录数(那种hardid，registercode没有值的记录视为无效) ; 这表明SendPublicFile 中的每个数据包会传给所有门店，可以利用此功能让所有门店执行某些Sql语句。

那么 SendPublicFile 是怎样产生的呢？

 

13、POS门店的会员功能对POS终端系统做了哪些改变,目前存在什么问题?

答：
POS门店的会员功能主要包括：

1、会员资料维护( 在线 增删改)
由于会员数量庞大，并且要求一家门店录入的会员能马上在其他门店被识别。所以采用了后台中心数据库集中管理的方式，门店的后台录入时采用web-Service的方式实时与后台中心数据库联系，实现在线 增删改的。

2、会员积分
目前在POS小票的头上记录了会员号；做会员销售时，必须录入会员号，通过Web-Service查询到会员的积分，显示到POS门店终端的销售界面，保存确认时，通过Web-Service的方式实时传到后台中心数据库。同时为了防止小票在日结以后，通过通讯的方式重复传入后台中心数据库，保存到POS门店的SqlServer数据库时，把SendData 改成了’Y’(表示已上传) ; 但是不改变SellStateID(SellStateID默认为01表示未汇总，汇总后会被更改为”02”) ; 所以在做日结的时候，会员销售的销售小票会被汇总到销售日报，但是不会被通讯程序再次上传。

3、会员促销
分公司的人员会在POS后台维护优惠券（其实就是变价促销单），这些促销单仅维护了(修改量,而没有维护限定词，没有限定词的情况下，POS 终端解析为没有任何限定词可以应用此修改量。所以这些促销单不会被普通销售界面自动执行到。需要在做会员销售的时候输入会员号和变价促销单号码，这时门店终端程序对本次销售应用此促销变价单。系统会自动根据变价单重新计算销售价，同时在一张Log表中记录某某会员曾经使用某某变价单。系统控制一个会员对同一张变价单只用应用一次。
会员销售时应用促销变价单与普通销售应用促销变价单的区别是：
1) 普通销售应用促销变价单: 在后台录入时，已经明确了修改量+限定词，通讯到POS终端以后由终端自动解析,自动应用。无需人为干预。
2) 会员销售应用促销变价单: 在后台录入时，已经明确了修改量,但没有明确限定词，通讯到POS终端以后，终端无法自动解析,自动应用。需要人为指定才能在某笔销售中被应用。

备注： 目前后台维护人员在维护 优惠券（其实就是变价促销单）后，会根据一定条件来筛选会员，然后给这些会员发短信，告诉他们最近你可以享受哪个促销单号。会员根据此短信到专卖店，专卖店店员根据会员手机上的短信确认此顾客可以享受本次会员优惠销售。

 

14、基础数据不能发布的问题

现象：
1、基础数据发布的JOB 运行结果为正常

2、基础数据的发布配置信息正常
3、基础数据并没有实际发布成功，基础数据表的senddata,alreadysend标记还是为’N’; 导入到处日志显示有”Stream write error”

4、产品基本信息被发布出去以后，productmaindorrsior 表的senddata 和alreadysend标记没有变化为’Y’ ; storage表的senddata 和alreadysend也没有变化。

分析：到google 检索”Stream write error” 没有针对性的信息。

到底是我们的UAT5配置有问题，还是通讯服务器本身出了问题？

1、使用虚拟机,创建一台新的通讯服务器，更改transferserver 表中主通讯服务器器的记录。 重新运行myjobsvr.exe ; 结果基础数据被导出，productmaindorrsior 表的senddata 和alreadysend标记也变化为’Y’了，一切正常。说明我们的配置没有问题，是通讯服务器本身出问题了。

解决方案：

怀疑是问题通讯服务器的文件系统坏了，对D: 做磁盘检查，自动修复。重新启动后，自动做磁盘检查，在第5步非常慢，完成后自动重启。再重启通讯服务器后问题解决。

备注： 这个问题在192.168.0.174上也发生过，当时的情况也是有大量的基础数据被标记为N的情况下，发生这种问题的。解决方法同上,但是没有起到效果。

看来, 以前犯经验主义错误了，猜测是否一次性发布的内容太多导致缓冲溢出。 于是先把最大的表productmaindossier 设置成Y, 再次运行myjob ; 这次成功了。 除了productmaindossier外其他基础数据表都被打包到一个文件了。 这应该是设计者的一个失误，如果他把每种基础数据打成一个包，可能会好很多。否则，全部放到一起，就太大了。

再次把productmaindossier 设置成N, 再次运行myjob, 依然是Stream write error;

Productmaindossier 表有38万条记录，还是太多，按照商品的年份分成5份,分别更新成N 再发布。

Select COUNT(1) –0

From productmaindossier

Where putintoproductiondate >= to_date(‘2009-01-01’, ‘YYYY-MM-DD’)

AND putintoproductiondate <= to_date(‘2009-12-31’, ‘YYYY-MM-DD’)

Select COUNT(1) –14590

From productmaindossier

Where putintoproductiondate >= to_date(‘2008-01-01’, ‘YYYY-MM-DD’)

AND putintoproductiondate <= to_date(‘2008-12-31’, ‘YYYY-MM-DD’)

Select COUNT(1) –149808

From productmaindossier

Where putintoproductiondate >= to_date(‘2007-01-01’, ‘YYYY-MM-DD’)

AND putintoproductiondate <= to_date(‘2007-12-31’, ‘YYYY-MM-DD’)

Select COUNT(1) –71774

From productmaindossier

Where putintoproductiondate >= to_date(‘2006-01-01’, ‘YYYY-MM-DD’)

AND putintoproductiondate <= to_date(‘2006-12-31’, ‘YYYY-MM-DD’)

Select COUNT(1) –55421

From productmaindossier

Where putintoproductiondate >= to_date(‘2005-01-01’, ‘YYYY-MM-DD’)

AND putintoproductiondate <= to_date(‘2005-12-31’, ‘YYYY-MM-DD’)

Select COUNT(1) –88557

From productmaindossier

Where putintoproductiondate >= to_date(‘2004-01-01’, ‘YYYY-MM-DD’)

AND putintoproductiondate <= to_date(‘2004-12-31’, ‘YYYY-MM-DD’)

Select COUNT(1) –0

From productmaindossier

Where putintoproductiondate >= to_date(‘2003-01-01’, ‘YYYY-MM-DD’)

AND putintoproductiondate <= to_date(‘2003-12-31’, ‘YYYY-MM-DD’)

 

15、基础数据重新初始化的方法

基础数据的发布方法是通过 发布SQL语句先删除后插入的方法进行的，删除是根据主健进行，倘若某个时候后台的基础数据重新初始化过，比如员工信息的编码全部换过了，那么相当于主健也全部变掉了，那么如果门店原来有条员工记录：

编码=0001 姓名=张三。

后台的员工基础信息重新初始化后：

编码=A0001 姓名=张三。

那么后台重新发布到前台的SQL是：

Delete from personnelbaseinfo where personnelid =’ A0001’

Insert into personnelbaseinfo (personnelid….) values (’ A0001’…….)

这种做法删除不掉原来的 编码=0001 姓名=张三 这条记录，这会导致门店终端系统中有很多重复的垃圾数据，并且门店终端系统也无法判断哪条是对的。如果选择错误的人员，通讯到后台就可能出问题。

启发：有些基础数据的主健是Serials , 这种字段是在基础数据初始化的时候自动生成的，每次重新初始化就相当于重新生成了主健。这种基础数据的广播，一定要先给所有门店广播删除对应的基础数据表的Sql语句。

 

16、如何给门店广播SQL语句，让所有门店执行?

答:

0、 需要制作一个SQL语句的文本文件，然后压缩成ZIP包，命名规则是FYYYYMMDDHHMMSSNNN.zip

1、 SQL文本的例子如下：

<SQL DATABASENO=1 RECORDCOUNT=56>

delete from OUTWAREHOUSETYPE

</SQL>

2、在SENDFILEPUBLIC 表中添加一条记录，记录格式与其他记录类似，把文件号写成上文制作的zip包

备注： 门店通讯下载时是根据文件号排序的，所以要想让你制作的文件包被优先执行，那么只需要把你的文件包名称搞的比较小就可以了，但要注意不要跟sendfilemsg表中的其他文件号重复。

 

17、门店终端的店铺铺货收货查询的SQL是怎门拼出来的?

答: 是从PosDoubleTBQuery 和Possysparams 表拼出来的。

 

18、为什么有些门店把加价额的乘法系数理解为加法?

答: 门店加价表上的一个标志设置为Y,再重新发布，门店再接受能解决问题。

 

19、通讯过程中发布到门店的数据丢失怎么办？

答: 如果是单据丢失，只要在后台把send 标记改成N ,再在Proposmansger中手工重新发布一下就可以了。

 

20、通讯服务器的分工是如何进行的？

答: 通讯服务器分为主通讯服务器和辅助通讯服务器。

数据发布时，所有的数据包文件都保存在主通讯服务器。也就是说，不管哪个门店连接哪台通讯服务器。其下载文件时，通讯服务器都是从主通讯服务器获取文件的。所以每台辅助通讯服务器都必须能够访问 \\主通讯服务器\d$\ ; 否则会出错。

数据接收时，数据报文件的存放地点由服务端Usercenter表中的针对每个门店行的ServerAddr 决定。当终端程序在系统设置界面更改通讯服务器时，通讯服务器的地址会被写到终端Sqlserver中的Usercenter表中，但是终端更新次信息后不会上传服务器，所以若某个分公司的所有门店更改了通讯服务器，则通常的做法是：

1、检查并保证新的通讯服务器能访问主通讯服务器。

2、检查门店参数里面配置的通讯服务器能访问，后台Usercenter表中配置的该门店的ServerAddr\D$.

 

21、POS终端是如何与Sqlserver数据库联接的？

答：
1、主界面启动时，创建了应用级的临时数据集：Globalvar，并从connection.ini中读取主要连接参数，但这些参数中没有具体的Pos1或针Pos2数据库。

2、当用户点[选择商场] 按钮后，系统从RegisterCompanyInfo.xml读取数据到Datagrid 控件，RegisterCompanyInfo.xml中Rowdata. DataPath是记录具体的数据库的（比如Pos1或者Pos2）

3、当用户选择了某个具体门店后，系统获取DataPath的值，并赋值给Globalvar.Datasource ，组成一个完整的数据库联接字符串：Globalvar. AdoConStr

4、系统的每个Form都是用了Globalvar. 从中可以获取数据库联接字符串。这样每个Form就可以访问数据库了。

 

22、POS终端是如何加载菜单的？

答：
1、主界面启动时，在选择具体的门店前，菜单是从Menus.xml中加载的，当选择门店，并登陆营业员后，菜单是从数据库的posmenu表中加载的。值得注意的是如果想添加菜单，则菜单ID 还必须在accountspopedomst表中存在。

 

23、POS终端的每个Form是否有统一的入口函数？

答：是的，每个Form 的统一入口函数是：LoadChildForm ； 大部分Form初始化工作均在此过程完成，比如登陆人员，门店，数据库连接等等。比如销售界面的数据库连接就是在初始化后存放于DataModule1.database1 中。初始化过程中会调用函数遍历当前Form 上的所有AdoQuery 组件，给每个AdoQuery组件赋于连接字符串。

销售界面的销售明细使用了一个Datagrid , 我们能找到的关系是这样的：

1、 Datagrid 同时设置了Datasource 和Dataset属性。从属性上看，从Dataset方向看，看不出与数据库联接有何联系，从Datasource 方向看，也看不出与数据库联接有何联系。那么到底在哪里给出联系了呢？从代码中找所有涉及cdsitem和dscItem也未找到与数据库联接有关的地方。

文档完毕