Controlling contents of .cgi file

This is an archive of old posting to the User Forum

Controlling contents of .cgi file

Postby Stephen Wonfor » Tue Jan 28, 2003 11:00 am

Does Shopsite allow for any control of the contents of the .cgi files
that are downloaded?

My client uses ShopSite on their website, once a day one of their staff
will download new orders from the website backend. I look after their
inhouse databases [Filemaker Pro 5.5 and 6.0]. I set up an import
mapping between a temp database and the .cgi file - simple when it
works, just aim at the .cgi as source and import.

We run into problems when ShopSite adds new fields to the .cgi file, as
I need to re-map the data import. We get the data from ShopSite in a
long row per Order basis - since some Orders may be for 10 or more
products we had to add 10 Item groups [I think originally this was 5
items per group - seems it is now up to 8 or 9]. Everytime they change
their format requires addition of new fields to the db and hours of
remapping. FMPro is a somewhat unfriendly in this regard - if I need to
add a new field at position 40 I need to shuffle all fields below down
one position. If the new field is in the Item group I need to shuffle
all group 10 members down 10 positions, group 9 down 9 etc.

We tried to get around this by setting up an Excel macro that would
remove any columns from the .cgi file that did not have names that fell
within an array of column names we wanted. Two problems there -
sometimes ShopSite changes names and sometimes they may delete a data
element entirely. Also had issues with Excel rounding the 16 digit
credit card numbers to 15 digits.

If I could control the form of the .cgi file then all or most of this
will go away. Is this a possibility?

Stephen

--
Weenix /wee'niks/ n. 1. [ITS] A derogatory term for Unix, derived from
Unix weenie. According to one noted ex-ITSer, it is "the operating
system preferred by Unix Weenies: typified by poor modularity, poor
reliability, hard file deletion, no file version numbers, case
sensitivity everywhere, and users who believe that these are all
advantages". http://www.tuxedo.org/~esr/jargon/jargon.html
Stephen Wonfor
 

Re: Controlling contents of .cgi file

Postby loren_d_c » Tue Jan 28, 2003 11:14 am

As of ShopSite v6.2x you can choose to download the Orders database in
formats from several previous versions (All versions back to 4.3).

-Loren


Stephen Wonfor wrote:

Does Shopsite allow for any control of the contents of the .cgi files
that are downloaded?

My client uses ShopSite on their website, once a day one of their staff
will download new orders from the website backend. I look after their
inhouse databases [Filemaker Pro 5.5 and 6.0]. I set up an import
mapping between a temp database and the .cgi file - simple when it
works, just aim at the .cgi as source and import.

We run into problems when ShopSite adds new fields to the .cgi file, as
I need to re-map the data import. We get the data from ShopSite in a
long row per Order basis - since some Orders may be for 10 or more
products we had to add 10 Item groups [I think originally this was 5
items per group - seems it is now up to 8 or 9]. Everytime they change
their format requires addition of new fields to the db and hours of
remapping. FMPro is a somewhat unfriendly in this regard - if I need to
add a new field at position 40 I need to shuffle all fields below down
one position. If the new field is in the Item group I need to shuffle
all group 10 members down 10 positions, group 9 down 9 etc.

We tried to get around this by setting up an Excel macro that would
remove any columns from the .cgi file that did not have names that fell
within an array of column names we wanted. Two problems there -
sometimes ShopSite changes names and sometimes they may delete a data
element entirely. Also had issues with Excel rounding the 16 digit
credit card numbers to 15 digits.

If I could control the form of the .cgi file then all or most of this
will go away. Is this a possibility?

Stephen

--
Weenix /wee'niks/ n. 1. [ITS] A derogatory term for Unix, derived from
Unix weenie. According to one noted ex-ITSer, it is "the operating
system preferred by Unix Weenies: typified by poor modularity, poor
reliability, hard file deletion, no file version numbers, case
sensitivity everywhere, and users who believe that these are all
advantages". http://www.tuxedo.org/~esr/jargon/jargon.html
loren_d_c
 
Posts: 2571
Joined: Fri Aug 04, 2006 12:02 pm
Location: Anywhere


Return to User Forum Archive

Who is online

Users browsing this forum: No registered users and 15 guests