Tamten selekt jest błędny (brak takiego pola jak f_company).
Tabela crm_meeting_data_1 wygląda tak:
(
id serial NOT NULL,
created_on timestamp without time zone,
created_by integer,
private integer DEFAULT 0,
active smallint DEFAULT 1,
f_title character varying(255),
f_description text,
f_date date,
f_time timestamp without time zone,
f_duration integer,
f_employees text,
f_customers text,
f_status character varying(128),
f_priority character varying(128),
f_permission character varying(128),
f_recurrence_type integer,
f_recurrence_end date,
f_recurrence_hash character varying(16),
f_produkty text,
f_oldcrm_id integer,
f_prezentacja smallint,
f_typ_wydarzenia text,
f_szansa_sprzedazy character varying(128),
f_opportunity integer,
CONSTRAINT crm_meeting_data_1_pkey PRIMARY KEY (id)
)
Osoby i firmy do których jest wydarzenie trzymane są w jednej kolumnie czyli f_customers jako tekst. Zawartość tego pola może wyglądać np. w taki sposób: __C:12345__P:54321__P:6789__
gdzie __C:XXXX__ to firma do której powstało wydarzenie jeżeli ktoś robił bezpośrednio do firmy a __P:XXXX__ to pracownik do którego było robione wydarzenie.
Nie ma prostego sposobu na połączenie tego ze sobą, bo albo trzeba dane pośrednio obrabiać albo zrzucenie całej zawartości trwa wieki. No chyba, że się mylę.
P.S.
Moim zdaniem informacja o osobach uczestniczących w wydarzeniu powinna być przeniesiona do oddzielnych tabel. Przykład dla pracowników:
crm_meeting_data_1_customers
(
id serial NOT NULL,
created_on timestamp without time zone,
created_by integer,
private integer DEFAULT 0,
active smallint DEFAULT 1,
f_customers id,
crm_meeting_id id,
CONSTRAINT crm_meeting_data_1_pkey PRIMARY KEY (id)
)
Taka tabela ma trzy pola: własne ID rekordu, ID pracownika i ID wydarzenia do którego ten pracownik jest.
