Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mRCn1-0005DT-Uy for pgsql-odbc@arkaria.postgresql.org; Fri, 17 Sep 2021 12:16:24 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mRCn0-0002Tr-V2 for pgsql-odbc@arkaria.postgresql.org; Fri, 17 Sep 2021 12:16:22 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mRCn0-0002Tj-J4 for pgsql-odbc@lists.postgresql.org; Fri, 17 Sep 2021 12:16:22 +0000 Received: from mail-ed1-x52d.google.com ([2a00:1450:4864:20::52d]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mRCmx-0006zX-ID for pgsql-odbc@postgresql.org; Fri, 17 Sep 2021 12:16:22 +0000 Received: by mail-ed1-x52d.google.com with SMTP id t6so29228444edi.9 for ; Fri, 17 Sep 2021 05:16:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=H8T44zAyqCDqT3tY0O+HgrRDiy0TEA6Z8NJMPtiEmNM=; b=KjtT3ge12RCrbnYSAivTKuN30m7lkyn8QwwNCahuA0qI300BAjfa+6ibJOTFIbzAc1 TEoeUWq+59BPq1G0SyIZ6NLSEDPAzfGZRXhRdYtI0GzHebsX8m9HFs7rnGgRlE0emHlZ DxghexdZS5ZTXZLhaDkDoiLUa85xwzkhWulRAdk7VO2mKsBXV7dLyCRsg38pV8M7ml/h eBH0d6XKIp8rJWgZmzjGYMAteOemT5KqbIqQdxNcT3FnZVY/uc092IkQYH3DZlAtaZ26 rTnePRxtBYwZpL+LW8GeyET/RwDyCuXdMZhd2x1W9R+8CukJMmP4VkEzgm/g/fLVPj/a pPYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=H8T44zAyqCDqT3tY0O+HgrRDiy0TEA6Z8NJMPtiEmNM=; b=r595nZudQ32M/llE+ICAoBwGYwxZ5jAKOdIuJvccXFsIEF+zYMbdR3MUd4+myJBKt8 Mz/ZmUizMYDUw/Bni8YrfhuqbBmrznys3A/I77p6v5mTHshPbcLpDyR+IP3crdzDUud0 iPufMrPe8gc4ageeRUfmotwsqAxCfprB/R6I/chleEFdNeRu5oGkloFG8Xsg1T+TCdDj 0HweNEf2nqUDD3kBGunu1soilIhPrAFche/BSUsXzEYZ3PBpYDgv+JJDnXJCypIsXEod 2M7BFCb/J1vBepxOe4tmMo5gMsmOFb3a4X6dj0uneGh3J82Wy9TzQdbKaOK1qkhhG7ww oq4A== X-Gm-Message-State: AOAM532d/75imXYxNIILeW7zitMuFWIzZE/MlAcKx263uND3ycda2KkV tBJl68cgKBU6vCgFyOa5ciPRdkY+cFzz2mHGe7s= X-Google-Smtp-Source: ABdhPJzZoBxGmctsrr2PpCeWyoq+Mrne+DWyJNbW/saReBzrrjJLrXjymoaygk7aY1CItgOTkDQvCulwAYRrjsS5v94= X-Received: by 2002:a50:954c:: with SMTP id v12mr12029273eda.313.1631880978267; Fri, 17 Sep 2021 05:16:18 -0700 (PDT) MIME-Version: 1.0 References: <994c12dd0d6348d389246fda802fff07@exmbx03.ofis.int> <20f6a96a81274049a0b9eacdf79bce20@exmbx03.ofis.int> <4bf3968b135d4ac1822812f7954c0e29@exmbx03.ofis.int> In-Reply-To: <4bf3968b135d4ac1822812f7954c0e29@exmbx03.ofis.int> From: "Inoue,Hiroshi" Date: Fri, 17 Sep 2021 21:16:05 +0900 Message-ID: Subject: Re: Problem on calling procedures with ADODB To: Kamil ADEM Cc: Adrian Grucza , "pgsql-odbc@postgresql.org" , Haluk DALKIRAN Content-Type: multipart/related; boundary="000000000000069b1405cc2fe61e" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000069b1405cc2fe61e Content-Type: multipart/alternative; boundary="000000000000069b1305cc2fe61d" --000000000000069b1305cc2fe61d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, We will make a new release next weekend. regards, Hiroshi Inoue 2021=E5=B9=B49=E6=9C=8817=E6=97=A5(=E9=87=91) 20:00 Kamil ADEM : > Hi Adrian, > > > > Thank you very much for your precious support. I will follow the steps yo= u > suggested. > > > > Have a nice day! > > > > Kamil Adem > > Aqvila Software Yaz=C4=B1l=C4=B1m A.=C5=9E. > > > > *From:* Adrian Grucza > *Sent:* Friday, September 17, 2021 1:47 PM > *To:* Kamil ADEM > *Cc:* pgsql-odbc@postgresql.org; Haluk DALKIRAN > > *Subject:* Re: Problem on calling procedures with ADODB > > > > Hi Kamil, > > > > That particular commit does actually depend on the previous commit. But t= o > fix your particular problem, you should only need the below change (which > doesn't have dependencies): > > > > --- a/statement.c > > > +++ b/statement.c > > > @@ -56,6 > > +56,9 > > @@ static const struct > > ,{ > > STMT_TYPE_DELETE, "DELETE" > > } > > + ,{ > > + STMT_TYPE_PROCCALL, "CALL" > > + } > > ,{ > > STMT_TYPE_PROCCALL, "{" > > } > > > > Alternatively, just build with the latest code from the master branch. > > > > I'm not part of the psqlODBC team so I'm not aware of the release > schedule. But whenever a new version is released, a message is posted on > this mailing list, so just stay subscribed. > > > > > > > > [image: Image removed by sender.] > > *Adrian Grucza**=E2=80=8B* > > Technical Lead > > Tel: > > +61390185800 > > The contents of this email originated from Iress. For this purpose Iress > includes Iress Limited and/or any of its subsidiaries, holding companies > and trading entities. > =E2=80=8B=E2=80=8BIf you have received this email in error please notify = the sender > immediately and delete this email. > > On Fri, 17 Sept 2021 at 17:43, Kamil ADEM > wrote: > > > > *CAUTION: *This Email is from an EXTERNAL source. Ensure you trust this > sender before clicking on any links or attachments. > > > > Hi Adrian, > > > > Thank you for your comment. > > I will work for our own version to include your fix. I hope this fix has > no dependencies to other fixes not included in the source code I have. I > think I can ask for help from you if I get a problem when building and > testing. > > > > We also are very keen to have a recent release that contains all the > recent fixes. We are going to publish our old application with a new > PostgreSQL interface and want to have a solid working environment. > > How can we follow the release schedule? Is there an automatic mechanism o= r > can you inform us when a new release comes out? > > > > Kamil Adem > > Aqvila Software Yaz=C4=B1l=C4=B1m A.=C5=9E. > > > > > > *From:* Adrian Grucza > *Sent:* Friday, September 17, 2021 2:21 AM > *To:* Kamil ADEM > *Cc:* pgsql-odbc@postgresql.org > *Subject:* Re: Problem on calling procedures with ADODB > > > > Hi Kamil, > > > > Yes I also found that output parameters were not processed when calling > procedures. In May I included a fix for this in the below commit, but the= re > has not been a release of psqlODBC since then. > > > > > https://git.postgresql.org/gitweb/?p=3Dpsqlodbc.git;a=3Dcommit;h=3D241c70= bf6516bf08770fabcb1b86934c8da116c8 > > > > > Until this change is released, you would have to build your own version o= f > the driver as per https://odbc.postgresql.org/docs/win32-compilation.html > > > > > But I do hope there will be a new release soon, as I too am keen to have > an official release that contains this fix. > > > > > > > > [image: Image removed by sender.] > > *Adrian Grucza* > > Technical Lead > > Tel: > > +61390185800 > > The contents of this email originated from Iress. For this purpose Iress > includes Iress Limited and/or any of its subsidiaries, holding companies > and trading entities. > If you have received this email in error please notify the sender > immediately and delete this email. > > On Thu, 16 Sept 2021 at 23:23, Kamil ADEM > wrote: > > > > *CAUTION: *This Email is from an EXTERNAL source. Ensure you trust this > sender before clicking on any links or attachments. > > > > Hi Adrian, > > > > Thank you very much for your support. > > > > Yes, I tried setting CommandText as you propose and succeeded to call the > procedure. But I got another minor problem this time. I hope you have a > solution for this too. =F0=9F=98=8A > > To be more clear, here are the source codes: > > Postgres procedure: > > CREATE OR REPLACE PROCEDURE public.SP_TEST(INOUT VALUE_INOUT INTEGER, IN > USERNAME VARCHAR(50)) > > LANGUAGE plpgsql > > AS $$ > > BEGIN > > insert into tohal_kullanici (satis_faturasi_sira_no, ad) > values (VALUE_INOUT, USERNAME); > > VALUE_INOUT :=3D 20; > > RETURN; > > END; $$; > > MFC code: > > _CommandPtr pCommand; > > pCommand->CommandType =3D adCmdText; > > pCommand->CommandText =3D _bstr_t("CALL SP_TEST(?, ?)"); > > pCommand->Parameters->Append(pCommand->CreateParameter(_bstr_t("$1"), > adInteger, adParamInputOutput, 0)); > > pCommand->Parameters->Append(pCommand->CreateParameter(_bstr_t("$2"), > adVarChar, adParamInput, 255)); > > pCommand->Parameters->Item[_variant_t((long)1)]->Value =3D > _variant_t(CString("Test10")); > > pCommand->Parameters->Item[_variant_t((long)0)]->Value =3D > _variant_t((long)10); > > pCommand->Execute(NULL, NULL, adCmdText); > > > > The procedure is called and the parameter values are passed correctly to > the procedure. But the first parameter value is not returned to the C cod= e, > the value set before Execute() remains unchanged. > > Do you have any idea about the reason of this case? > > > > Thanks in advance. > > > > Kamil Adem > > > > > > *From:* Adrian Grucza > *Sent:* Thursday, September 16, 2021 2:07 PM > *To:* Kamil ADEM > *Cc:* pgsql-odbc@postgresql.org > *Subject:* Re: Problem on calling procedures with ADODB > > > > Hi Kamil, > > > > Have you tried changing pCommand->CommandText to _bstr_t("CALL sp_TEST(?, > ?, ?)"), with one question mark per parameter? > > > > [image: Image removed by sender. iress.com] > > *Adrian Grucza * > > Technical Lead > > Tel: > > +61390185800 > > *adrian.grucza@iress.com* > > *www.iress.com* > > Level 16 385 Bourke St > > Melbourne, > > Victoria, > > 3000 > > The contents of this email originated from Iress. For this purpose Iress > includes Iress Limited and/or any of its subsidiaries, holding companies > and trading entities. If you have received this email in error please > notify the sender immediately and delete this email. > > nosig > > On Thu, 16 Sept 2021 at 17:49, Kamil ADEM > wrote: > > > > *CAUTION: *This Email is from an EXTERNAL source. Ensure you trust this > sender before clicking on any links or attachments. > > > > Hello, > > > > We porting a Windows MFC application from MSSQLServer to PostgreSQL and > trying to use psqlODBC driver with Microsoft ADODB. > > We are currently performing the migration steps of our C sources and got > stuck on an issue and thought to ask for your help. > > > > We use Microsoft ADODB on Windows to access the database and cannot chang= e > this interface in short time. To access Postgres we changed the connectio= n > string accordingly. (e.g. =E2=80=9CDriver=3D {PostgreSQL ANSI};=E2=80=9D) > > On calling Postgres procedures we have the following code sample: > > _CommandPtr pCommand; > > pCommand->CommandType =3D adCmdStoredProc; > > pCommand->CommandText =3D _bstr_t(=E2=80=9Csp_TEST=E2=80=9D); > > pCommand->Parameters->Refresh(); > > pCommand->Execute(NULL, NULL, adCmdStoredProc | adExecuteNoRecords); > > The Execute() method generates the command: =E2=80=9CSELECT * FROM sp_TES= T(=E2=80=A6)=E2=80=9D > instead of =E2=80=9CCALL sp_TEST(=E2=80=A6)=E2=80=9D. This is appropriate= for Postgres functions, > but there must be a way to call procedures also. > > Do you know such a reported issue? Do you know a way to change this > behaviour? Should we use a different driver? Should we get rid of > procedures and convert our MSSQL stored procedures to Postgres functions? > > > > We would be grateful if you can guide us to the right solution. > > Thanks in advance. > > > > Best regards, > > > > Kamil Adem > > Aqvila Software Yaz=C4=B1l=C4=B1m A.=C5=9E. > > > > > > > > --000000000000069b1305cc2fe61d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

We will make a new release next wee= kend.

regards,
Hiroshi Inoue

2021=E5=B9=B49=E6=9C=8817=E6=97=A5(=E9=87=91) 20:00 Kamil ADEM= <kamila@aqvilasoftware.com= >:

Hi Adrian,

=C2=A0

Thank you very much for your precious support.= I will follow the steps you suggested.

=C2=A0

Have a nice day!

=C2=A0

Kamil Adem<= u>

Aqvila Software Yaz=C4=B1l=C4= =B1m A.=C5=9E.

=C2=A0

From: Adrian Grucza <adrian.grucza@iress.com>
Sent: Friday, September 17, 2021 1:47 PM
To: Kamil ADEM <kamila@aqvilasoftware.com>
Cc: p= gsql-odbc@postgresql.org; Haluk DALKIRAN <halukd@aqvilasoftware.com>
Subject: Re: Problem on calling procedures with ADODB<= /span>

=C2=A0

Hi Kamil,

=C2=A0

That particular commit does actually depend on the p= revious commit. But to fix your particular problem, you should only=C2=A0ne= ed the below change (which doesn't have dependencies):

=C2=A0

--- a/statement.c

+++ b/statement.c

@@ -56,6 +56,9 @@=C2=A0static=C2=A0const= =C2=A0struct

=C2=A0=C2=A0=C2=A0=C2=A0,{

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0STMT_TYPE_DELET= E,=C2=A0"DELETE"

=C2=A0=C2=A0=C2=A0=C2=A0}

+=C2=A0=C2=A0=C2=A0,{

+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0STMT_TYPE_PRO= CCALL,=C2=A0"CALL"

+=C2=A0=C2=A0=C2=A0}

=C2=A0=C2=A0=C2=A0=C2=A0,{

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0STMT_TYPE_PROCC= ALL,=C2=A0"{"

=C2=A0=C2=A0=C2=A0=C2=A0}

=C2=A0

Alternatively, just build with the latest code from = the master branch.

=C2=A0

I'm not part of the psqlODBC team so I'm not= aware of the release schedule. But whenever a new version is released, a m= essage is posted on this mailing list, so just stay subscribed.

=C2=A0

=C2=A0

=C2=A0

3D"Image<= /span>

Adrian=C2=A0Grucza=E2=80=8B

Technical=C2=A0Lead

Tel:=C2=A0

+61390185800

The contents of this email o= riginated from Iress. For this purpose Iress includes Iress Limited and/or = any of its subsidiaries, holding companies and trading entities.
=E2=80=8B=E2=80=8BIf you have received this email in error please notify th= e sender immediately and delete this email.=C2=A0

On Fri, 17 Sept 2021 at 17:43, Kamil ADEM <kamila@aqvilasoftw= are.com> wrote:

=C2=A0

CAUTION: This Email is from an EXTERNAL source. Ensure you trust this sen= der before clicking on any links or attachments.

=C2=A0

Hi Adrian,=

=C2=A0

Thank you for your comment.

I will work for our own version= to include your fix. I hope this fix has no dependencies to other fixes no= t included in the source code I have. I think I can ask for help from you if I get a problem when building and testing.=

=C2=A0

We also are very keen to have a= recent release that contains all the recent fixes. We are going to publish= our old application with a new PostgreSQL interface and want to have a solid working environment.

How can we follow the release s= chedule? Is there an automatic mechanism or can you inform us when a new re= lease comes out?

=C2=A0

Kamil Adem=

Aqvila Software Yaz=C4=B1l=C4= =B1m A.=C5=9E.

=C2=A0

=C2=A0

From: Adrian Grucza <adrian.grucza@iress.com>
Sent: Friday, September 17, 2021 2:21 AM
To: Kamil ADEM <kamila@aqvilasoftware.com>
Cc: p= gsql-odbc@postgresql.org
Subject: Re: Problem on calling procedures with ADODB<= u>

=C2=A0

Hi=C2=A0Kamil,

=C2=A0

Yes I also found that output parameters were not pro= cessed when calling procedures. In May I included a fix for this in the bel= ow commit, but there has not been a release of psqlODBC since then.

=C2=A0

=C2=A0

=C2=A0

But I do hope there will be a new release soon, as I= too am keen to have an official release that contains this fix.<= /u>

=C2=A0

=C2=A0

=C2=A0

3D"I=

Adrian=C2=A0Grucza

Technical=C2=A0Lead

Tel:=C2=A0

+61390185800

The contents of this email o= riginated from Iress. For this purpose Iress includes Iress Limited and/or any of its subsidiaries, holding companies and trading enti= ties.
If you have received this email in error please notify the sender immediate= ly and delete this email.=C2=A0

On Thu, 16 Sept 2021 at 23:23, Kamil ADEM <kamila@aqvilasoftw= are.com> wrote:

=C2=A0

CAUTION: This Email is from an EXTE= RNAL source. Ensure you trust this sender before clicking on any links or a= ttachments.

=C2=A0

Hi Adrian,=

=C2=A0

Thank you very much for your su= pport.

=C2=A0

Yes, I tried setting CommandTex= t as you propose and succeeded to call the procedure. But I got another min= or problem this time. I hope you have a solution for this too. =F0=9F=98=8A

To be more clear, here are the = source codes:

Postgres procedure:

CREATE OR REPLACE PROCEDURE public.SP_TEST(INOUT VALUE= _INOUT INTEGER, IN USERNAME VARCHAR(50))

LANGUAGE plpgsql

=C2=A0=C2=A0 AS $$

BEGIN

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 insert into tohal_kullanici (satis_fat= urasi_sira_no, ad) values (VALUE_INOUT, USERNAME);

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 VALUE_INOUT :=3D 20;<= /u>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RETURN;

END; $$;

MFC code:<= /p>

_CommandPtr pCommand;

pCommand->CommandType =3D adCmdText;<= u>

pCommand->CommandText =3D _bstr_t("CALL SP_TES= T(?, ?)");

pCommand->Parameters->Append(pCommand->Create= Parameter(_bstr_t("$1"), adInteger, adParamInputOutput, 0));

pCommand->Parameters->Append(pCommand->Create= Parameter(_bstr_t("$2"), adVarChar, adParamInput, 255));

pCommand->Parameters->Item[_variant_t((long)1)]-= >Value =3D _variant_t(CString("Test10"));=

pCommand->Parameters->Item[_variant_t((long)0)]-= >Value =3D _variant_t((long)10);

pCommand->Execute(NULL, NULL, adCmdText);=

=C2=A0

The procedure is called and the= parameter values are passed correctly to the procedure. But the first para= meter value is not returned to the C code, the value set before Execute() remains unchanged.

Do you have any idea about the = reason of this case?

=C2=A0

Thanks in advance.

=C2=A0

Kamil Adem=

=C2=A0

=C2=A0

=C2=A0

Hi Kamil,

=C2=A0

Have you tried changing pCommand->CommandText to = _bstr_t("CALL sp_TEST(?, ?, ?)"), with one question mark per para= meter?

=C2=A0

3D"Image=

Adrian=C2=A0Grucza=C2=A0=C2=A0<= /u>

Technical=C2=A0Lead

Tel:=C2=A0

+61390185800

adrian.gruc= za@iress.com

www.iress.com

Level=C2=A016=C2=A0385=C2=A0Bourke=C2=A0St

=C2=A0Melbourne,=C2=A0

Victoria,=C2=A0

3000

The contents of this email originated from Iress. F= or this purpose Iress includes Iress Limited and/or any of its subsidiaries= , holding companies and trading entities. If you have received this email in error please notify the sender immediat= ely and delete this email.=C2=A0

nosig

On Thu, 16 Sept 2021 at 17:49, Kamil ADEM <kamila@aqvilasoftw= are.com> wrote:

=C2=A0

CAUTION: This Email is from an EXTE= RNAL source. Ensure you trust this sender before clicking on any links or a= ttachments.

=C2=A0

Hello,

=C2=A0

We porting a Windows MFC applic= ation from MSSQLServer to PostgreSQL and trying to use psqlODBC driver with= Microsoft ADODB.

We are currently performing the= migration steps of our C sources and got stuck on an issue and thought to = ask for your help.

=C2=A0

We use Microsoft ADODB on Windo= ws to access the database and cannot change this interface in short time. T= o access Postgres we changed the connection string accordingly. (e.g. =E2=80=9CDriver=3D {PostgreSQL ANSI};=E2=80=9D)=

On calling Postgres procedures = we have the following code sample:

_CommandPtr pCommand;

pCommand->CommandType =3D adCmdStoredProc;

pCommand->CommandText =3D _bstr_t(=E2=80=9Csp_TEST= =E2=80=9D);

pCommand->Parameters->Refresh();

pCommand->Execute(NULL, NULL, adCmdStoredProc | adE= xecuteNoRecords);

The Execute() method generates = the command: =E2=80=9CSELECT * FROM sp_TEST(=E2=80=A6)=E2=80=9D instead of = =E2=80=9CCALL sp_TEST(=E2=80=A6)=E2=80=9D. This is appropriate for Postgres= functions, but there must be a way to call procedures also.

Do you know such a reported iss= ue? =C2=A0Do yo= u know a way to change this behaviour? Should we use a different driver? Sh= ould we get rid of procedures and convert our MSSQL stored procedures to Po= stgres functions?

=C2=A0

We would be grateful if you can guide us to the = right solution.

Thanks in advance.

=C2=A0

Best regards,<= /u>

=C2=A0

Kamil Adem=

Aqvila Software Yaz=C4=B1l=C4= =B1m A.=C5=9E.

=C2=A0

=C2=A0

=C2=A0

--000000000000069b1305cc2fe61d-- --000000000000069b1405cc2fe61e Content-Type: image/jpeg; name="~WRD0005.jpg" Content-Disposition: inline; filename="~WRD0005.jpg" Content-Transfer-Encoding: base64 Content-ID: <17bf39f4f4abf2963031> X-Attachment-Id: 17bf39f4f4abf2963031 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABkAGQDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3+iii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigD//2Q== --000000000000069b1405cc2fe61e--