[Date Prev][Date Next][Thread Prev][Thread Next][Interchange by date
][Interchange by thread
]
[ic] Two catalogs one products table
Mike Heins wrote:
>Quoting Brian Kosick (briank@nacs.net):
>
>
>>Mike Heins wrote:
>>
>><SNIP>
>>
>>
>>
>>>>
>>>>
>>>>
>>>>
>>>Not knowing what the problem is, I suspect that you are the victim of a
>>>default [query ...] somewhere. You would need [query base=merchandising
>>>...] instead.
>>>
>>>
>>>
>>>
>>>
>>The problem is that I'm trying to share the products table of one site
>>(site1) with another site(site2) I did it by specifing
>>a new SQLDSN variable and then editing the products pgsql file to use
>>the new DSN.
>>
>>
>
>This is all fine, but you are assuming facts not in evidence here. Like
>the original behavior you are talking about. Trying to read your mind,
>I am guessing your original problem is that the "promo" component
>doesn't work.
>
>Did you try what I said? Look for a [query ...] calling merchandising?
>Like the one in templates/components/promo?
>
>There is no other reason that anything would return things from
>the Products DSN. [query ...] must have a base table to try and
>query on. This has been covered on the mail list innumerable times.
>
>
>
Mike, I don't think that we're syncing on this.....
<me takes deep breath>
Two sites on the same server they're exactly the same except for the
color scheme and that one accepts insurance (site2), and the other
(Site1) doesn't. They both use postgres 7.3 on a seperate db server.
Other than price the products offered are exactly the same. So in
site1's products table I added a new price (dc_price) column for (site2)
prices. Then in site2's catalog.cfg I modified the following
--------------------
ifndef SQLDSN
Variable SQLDSN dbi:Pg:dbname=site2@db.server.net
Variable DEXPRESSSQLDSN dbi:Pg:dbname=site1@db.server.net
endif
CommonAdjust ;dc_price, ;$, ==:options
PriceField dc_price
--------------------------
in dbconf/pgsql/products.pgsql I changed the first line.
-------------------------------------
Database products products.txt __SQLDSN__
to
Database products products.txt __DEXPRESSSQLDSN__
-------------------------------------
This works great pricing and everything shows up correctly *except* for
the merchandising table.
My original problem was not that the promo component didn't work but
that the promo component was using the merchandising table from site1 as
well as the products (site1) table. I ONLY wanted it to use the
products (site1) table. So that I could have seperate merchandising on
site2. I tried to switch site2's merchandising table to a DBM file. I
removed the dbconf/pgsql/merchandising.pgsql and replaced it with
dbconf/pgsql/merchandising.dbm next I made sure that site2's
merchandising.txt was empty except for the column names/titles line, and
removed the merchandising.gdbm ,.sql, .autonumber and restarted IC.
Site2 still looked at site1's merchandising table. This does not
happen with any other site2 database table except for merchandising
So in site2's db I created a table "merchandising_dc" to distinguish
between the two.....
Yes, there is a query tag that you specified in the promo, though I'm
not sure whay this would be relevant in my case. If it is, then please
explain to me why. If I modify the query tag in the front end and all
the components etc
[query arrayref=main
sql="
SELECT sku,timed_promotion,start_date,finish_date
FROM
[either]__UI_MERCH_TABLE__[or]merchandising[/either]
WHERE featured = '[control promo_type specials]'
"][/query]
to use "merchandising_dc" on site2 rather than "merchandising" on site1,
I could fix the front end, but then the admin area would be broken as
the admin pages look for the "merchandising" table rather than
"merchandising_dc". (This is where I am currrently stuck at as I used
"Variable UI_MERCH_TABLE merchandising_dc" in my work around. So my
front end now uses merchandising_dc, but the admin UI for site2's
merchandising is broken as it's looking for the non-existant table
merchandising rather than merchandising_dc on site2)
This is why I was wondering if there was an equivilent of the
ProductFiles Directive for Merchandising (or any other table for that
matter) as being able to remap merchandising_dc to merchandising would
fix everything for me.
I'm not asking for flames, I have searched the archives for using tables
on other databases, but none were all that helpfull in my particular
circumstance. I wouldn't bother everyone here on the list if I didn't
all ready try for figure it out for myself.
Thanks all!