Hello List,
Business Problem: We use the MAS200 application for corporate accounting, ProvideX database version. We have a large customer base of 22K active customers. There are ten outside sales representatives responsible for this customer base and receive commissions from that annual sales number. The distribution of responsibility/commissions among those sales reps is done by customer zip code. We have been managing this cross reference outside of MAS200, but would now like to use the AR_12CustomerContact table of MAS200 to store this territory designation. This sales force of ten has a regular turn over rate and or transferring of territories is regular business, 1000 to 5000 zip codes moved from one rep to another occurs monthly.
Proof of Concept: During this proof of concept phase, we purchased the ProvideX ODBC driver with the understanding that MS VisualBasic and ADO could gain access to all data fields for read, insert or update. We quickly discovered that the driver provides good read access to the fields of data in the AR_12CustomerContact file and transferring data
through the driver to MS/SQL using SQL Enterprise manager & DTS jobs can be done easily. As many of you may know the SQL Enterprise manager uses MS/ADO for these cross platform tasks. Now a quick VB application test, again reads worked fine, but updating started our challenges. After length padding code was added we began to gain some ground, then stop. It was discovered using the NOMADS utilities that there are two fields of data _S1 and _S2 that are not hidden by definition, but can not be seem by the driver/ADO/VB combination.
Question: Obvious, Why?, How do we get past this issue? Is there a fix, an undocumented secret?
Business Problem: We use the MAS200 application for corporate accounting, ProvideX database version. We have a large customer base of 22K active customers. There are ten outside sales representatives responsible for this customer base and receive commissions from that annual sales number. The distribution of responsibility/commissions among those sales reps is done by customer zip code. We have been managing this cross reference outside of MAS200, but would now like to use the AR_12CustomerContact table of MAS200 to store this territory designation. This sales force of ten has a regular turn over rate and or transferring of territories is regular business, 1000 to 5000 zip codes moved from one rep to another occurs monthly.
Proof of Concept: During this proof of concept phase, we purchased the ProvideX ODBC driver with the understanding that MS VisualBasic and ADO could gain access to all data fields for read, insert or update. We quickly discovered that the driver provides good read access to the fields of data in the AR_12CustomerContact file and transferring data
through the driver to MS/SQL using SQL Enterprise manager & DTS jobs can be done easily. As many of you may know the SQL Enterprise manager uses MS/ADO for these cross platform tasks. Now a quick VB application test, again reads worked fine, but updating started our challenges. After length padding code was added we began to gain some ground, then stop. It was discovered using the NOMADS utilities that there are two fields of data _S1 and _S2 that are not hidden by definition, but can not be seem by the driver/ADO/VB combination.
Question: Obvious, Why?, How do we get past this issue? Is there a fix, an undocumented secret?