Re: A cronjob for copying a table from Oracle

Поиск
Список
Период
Сортировка
От Dmitriy Igrishin
Тема Re: A cronjob for copying a table from Oracle
Дата
Msg-id AANLkTimpZ=k_jnh77qgEV61rqxcsf1XWW05gREsOXE_K@mail.gmail.com
обсуждение исходный текст
Ответ на Re: A cronjob for copying a table from Oracle  (Adrian Klaver <adrian.klaver@gmail.com>)
Ответы Re: A cronjob for copying a table from Oracle  (Adrian Klaver <adrian.klaver@gmail.com>)
Список pgsql-general
Hey Adrian,

2010/12/10 Adrian Klaver <adrian.klaver@gmail.com>
On Friday 10 December 2010 8:51:19 am Alexander Farber wrote:
> Please help, struggling since hours with this :-(
>
> I've created the following table (columns here and in the proc
> sorted alphabetically) to acquire data copied from Oracle:
>
> # \d qtrack
>                 Table "public.qtrack"
>    Column    |            Type             |   Modifiers
> -------------+-----------------------------+---------------
>  appsversion | character varying(30)       |
>  beta_prog   | character varying(20)       |
>  category    | character varying(120)      |
>  catinfo     | character varying(120)      |
>  details     | character varying(50)       |
>  devinfo     | character varying(4000)     |
>  emailid     | character varying(16)       |
>  email       | character varying(320)      |
>  formfactor  | character varying(10)       |
>  id          | character varying(20)       | not null
>  imei        | character varying(25)       |
>  name        | character varying(20)       |
>  osversion   | character varying(30)       |
>  pin         | character varying(12)       |
>  qdatetime   | timestamp without time zone |
>  copied      | timestamp without time zone | default now()
> Indexes:
>     "qtrack_pkey" PRIMARY KEY, btree (id)
>
> And for my "upsert" procedure I get the error:
>
> SQLSTATE[22001]: String data, right truncated: 7 ERROR:  value too
> long for type character varying(16)
>
> CONTEXT:  SQL statement "update qtrack set APPSVERSION =  $1 ,
> BETA_PROG =  $2 , CATEGORY =  $3 , CATINFO =  $4 , DETAILS =  $5 ,
> DEVINFO =  $6 , EMAIL =  $7 , EMAILID =  $8 , FORMFACTOR =  $9 , ID =
> $10 , IMEI =  $11 , NAME =  $12 , OSVERSION =  $13 , PIN =  $14 ,
> QDATETIME =  $15 , COPIED = current_timestamp where ID =  $10 "
> PL/pgSQL function "qtrack_upsert" line 2 at SQL statement


Looks like you got your EMAIL and EMAILID reversed. In your argument list
EMAILID is 7th but it is getting the 8th variable, the reverse for EMAIL.
Yes, but he refers arguments by name, rather than number. UPDATE statement
seems to be correct in the function definition.

>
> My "upsert" procedure is:
>
> create or replace function qtrack_upsert(
>         _APPSVERSION varchar,
>         _BETA_PROG   varchar,
>         _CATEGORY    varchar,
>         _CATINFO     varchar,
>         _DETAILS     varchar,
>         _DEVINFO     varchar,
>         _EMAILID     varchar,
>         _EMAIL       varchar,
>         _FORMFACTOR  varchar,
>         _ID          varchar,
>         _IMEI        varchar,
>         _NAME        varchar,
>         _OSVERSION   varchar,
>         _PIN         varchar,
>         _QDATETIME   timestamp
>         ) returns void as $BODY$
>         begin
>                 update qtrack set
>                         APPSVERSION = _APPSVERSION,
>                         BETA_PROG   = _BETA_PROG,
>                         CATEGORY    = _CATEGORY,
>                         CATINFO     = _CATINFO,
>                         DETAILS     = _DETAILS,
>                         DEVINFO     = _DEVINFO,
>                         EMAIL       = _EMAIL,
>                         EMAILID     = _EMAILID,
>                         FORMFACTOR  = _FORMFACTOR,
>                         ID          = _ID,
>                         IMEI        = _IMEI,
>                         NAME        = _NAME,
>                         OSVERSION   = _OSVERSION,
>                         PIN         = _PIN,
>                         QDATETIME   = _QDATETIME,
>                         COPIED      = current_timestamp
>                 where ID = _ID;
>
>                 if not found then
>                         insert into qtrack (
>                                 APPSVERSION,
>                                 BETA_PROG,
>                                 CATEGORY,
>                                 CATINFO,
>                                 DETAILS,
>                                 DEVINFO,
>                                 EMAIL,
>                                 EMAILID,
>                                 FORMFACTOR,
>                                 ID,
>                                 IMEI,
>                                 NAME,
>                                 OSVERSION,
>                                 PIN,
>                                 QDATETIME
>                         ) values (
>                                 _APPSVERSION,
>                                 _BETA_PROG,
>                                 _CATEGORY,
>                                 _CATINFO,
>                                 _DETAILS,
>                                 _DEVINFO,
>                                 _EMAIL,
>                                 _EMAILID,
>                                 _FORMFACTOR,
>                                 _ID,
>                                 _IMEI,
>                                 _NAME,
>                                 _OSVERSION,
>                                 _PIN,
>                                 _QDATETIME
>                         );
>                 end if;
>         end;
> $BODY$ language plpgsql;
>
> The weird thing is when I omit the 7th param
> in my PHP code as shown below, then it works:
>
>        $sth = $pg->prepare(SQL_UPSERT);
>        while (($row = oci_fetch_array($stid,
> OCI_NUM+OCI_RETURN_NULLS)) != false) {
>                $sth->execute(array(
>                 $row[0],
>                 $row[1],
>                 $row[2],
>                 $row[3],
>                 $row[4],
>                 $row[5],
>                 null, #$row[6],
>                 $row[7],
>                 $row[8],
>                 $row[9],
>                 $row[10],
>                 $row[11],
>                 $row[12],
>                 $row[13],
>                 $row[14])
>                 );
>       }
>
> And I'm very confused why it says varying(16)  in the error message.
> It should say varying(4000) instead.
>
> Isn't this a bug? The 6th overflows somehow and gets into 7th
>
> Please save me, I want to go home for weekend
> Alex



--
Adrian Klaver
adrian.klaver@gmail.com

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general



--
// Dmitriy.


В списке pgsql-general по дате отправления:

Предыдущее
От: Adrian Klaver
Дата:
Сообщение: Re: A cronjob for copying a table from Oracle
Следующее
От: Scott Mead
Дата:
Сообщение: Re: monitoring warm standby lag in 8.4?