Sounds like this could work. At the moment I have a heading table which contains common headings for each product range, so i could probably use the heading id number in product list to build <@DISTINCT> arrays. I'll have to investigate this further to see if it upsets some of the structure that I am currently using - due to the multiple levels of headings and groupings it is reasonably convoluted.
Also, as I have multiple ranges in any given search, I guess I would have to use a Direct DBMS action to create the necessary SQL to do this. However I am concerned that in a product list of 5000 items I might run into time delays? IMAGE NAMES problem At present I am considering how to organise the image names. Currently the expectation is to have them all named after the product code of the item, which works fine for the single items, but when it comes to a group of items in which the only difference is the colour, there will be only one image. The determining factor in this is that the shopper expects to be looking at the same image, no matter whether he pulls up a single item in the range (through a specific search) or whether he drills down by brand or product type and gets the whole product range displayed as a image, heading, text and colour-grid. Garth At 09:32 8/08/02 -0400, you wrote: >If you have a key that's common for a group of products (maybe the filename >of the image?), you can build a <@DISTINCT> array based on this column -- >then loop through this array, each time doing an <@FILTER> comparing the >curent image filename to the original database and building an array from >your <@FILTER> result. > >So each iteration through the DISTINCT you'll generate an array of products >that belong to the same image. > >- James > > >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED]]On Behalf Of Garth Penglase >Sent: Wednesday, August 07, 2002 10:40 AM >To: Multiple recipients of list witango-talk >Subject: Witango-Talk: Selective Arrays > > >Hi all, maybe you can help me with this... > >I have a large (reasonably complex) product database. Each product has a >alpha-numeric code and a unique ID and other product related things like >price, a flag for whether it is being discounted etc. A lot of the products >are simply one item, one price and displayed with one graphic. See example >at http://netramp.com.au/hhb/indola.jpg > >While all of these products are singular items and each has a price, some >of them (not all of them) are simply different shades of the same product, >and therefore there is only one graphic for the "main product" and in the >catalogue only one entry is displayed with a table for the colours. ie > >Wella Fresh Colour Liquid 3/0 Dark Brown >Wella Fresh Colour Liquid 5/0 Light Brown >Wella Fresh Colour Liquid 7/0 Medium Blonde >Wella Fresh Colour Liquid 8/0 Light Blonde >Wella Fresh Colour Liquid 5/66 Bordeaux >Wella Fresh Colour Liquid 6/4 Mahogany > >etc. (some have as many as 150 different colour/shades/combinations) > >The problem is that I want to separate these types of products out and >create an array for each which is then displayed as a table of colour >options (click on link above to see example), listed directly below the >main product image and header (thankfully, I have separate headings which >appear for product ranges - though these have also been manually added to >the database for each product range). > >In the past I had a manual process to create this for other sites, which >created separate external html files which were <@INCLUDE>ed whenever the >product range was called upon BUT now it is different, in that: >- the Internet product database is updated quarterly (in conjunction with >their magazine) and has constant changes to the product line >- Their internal systems are archaic and therefore at this juncture I >cannot get them to provide me with anything out of their product database >but a single flat file with all products each quarter, and maybe a 'changed >products' list (the maintenance issue of synchronising these two databases >is a doozy let me say, and that's a another issue which I'll have to be >creative with as well). > >My initial thought was to separate these product ranges out of the main >product database, leave one product range header item in the database >which, via a flag, when selected calls up a separate table of the range >colours which I then display as an array in tabular format. However, due to >the number of instances of this in the database, I can't see how it would >be feasible to do this each quarter. > >Does anyone have any idea of how I can, on a search where any of these >items comes up, force it to separate these items out into a separate array >for each instance of a product range like this being found/requested? > >thanks in advance for any ideas - I am hoping that I don't have to searpate >these product items out into a separate table, but I can't see a clean or >simple way of avoiding it. >Garth > > >________________________________________________________________________ >TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED] > with unsubscribe witango-talk in the message body > >________________________________________________________________________ >TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED] > with unsubscribe witango-talk in the message body ________________________________________________________________________ TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED] with unsubscribe witango-talk in the message body
