[Oledb-dev] Is it time for 1.0.0.20?

[Shachar Shemesh]

Victor Snezhko wrote:

>Shachar Shemesh <psql at shemesh.biz> writes:
>
>  
>
>>I'm thinking of releasing 1.0.0.20. The changes so far:
>>
>>- Fix for "OpenRowset"
>>
>>- Fix for BOOL type handling
>>
>>- Various cleanups
>>
>>These, in themselves, seem enough for me to justify a new version. I
>>will probably try to toss in the change of parameters required for
>>Crystal Reports support (but not the schema problems, as those are far
>>from trivial to handle).
>>
>>
>>If anyone has anything else they want put into the next version, now is
>>the time to speak up.
>>    
>>
>
>1) We have an issue with InlineIsEqualGUID on VC6. INSTALL file
>mentions KB243298, but is addresses different error. I have this one
>on VC6: 
>
>pgdbschemarowsetimpl.h(146) : error C2039: 'InlineIsEqualGUID' : is
>not a member of '`global namespace'' 
>
>I am forced to erase "::"'s, then pgoledb compiles.
>  
>
I know.

The answer is to install the latest Platform SDK from microsoft, or to
remove the ::. I'm afraid I have come to my wit's end in making this
work on all three combinations (VC6 without a platform SDK update,
VS.Net and VC6 with platform SDK update). At least the path from VC6 to
VC6 with platform SDK update is a possible one, so that's going to be my
official answer.

My unofficial answer is "just remove the ::".

>2) I have unfinished patches that make ADO Insert, Update and Delete
>work. I'll publish them later today, for now I'll just describe an
>issue I solved in a dirty way.
>
>Here is a sample javascript program:
>  adOpenStatic = 3;
>  adCmdTable = 2;
>  adUseClient = 3;
>  adLockOptimistic = 3;
>
>  var objRs = new ActiveXObject("ADODB.Recordset");
>  objRs.CursorLocation = adUseClient;
>  objRs.open("mytable", 
>    "Provider=PostgreSQL.1;Data Source=127.0.0.1;Location=mydb",
>    adOpenStatic,
>    adLockOptimistic,
>    adCmdTable);
>  objRs.MoveFirst();
>  objRs("strfield") = "my new string"
>  objRs.Update();
>  objRs.Close();
>
>table is something like:
>CREATE TABLE mytable (
>       keyfield serial,
>       strfield varchar(50),
>       PRIMARY KEY (keyfield)
>)
>
>When the program is executed, ADO generates the following query:
>UPDATE mytable SET strfield=? WHERE keyfield=? AND strfield=?
>
>The problem is that is does call SetParameterInfo() with zero
>parameter descriptions (cParams==0), but passes all the parameters
>directly in Execute(), via DBPARAMS pParams. Then in FillInValues() we
>have (cBindings!=num_params), and FillInValues fails.
>  
>
Hmm.

>My temporary "solution": When cBindings!=num_params, I just added
>parsing of the query to find names of parameters, and by names I
>retrieved oids of them. Parsing is done via pcre, thus adding one more
>dependency to the project.
>  
>
No, I do not want pcre in there at this point. I don't think regexp are
the right way to parse an SQL query (for example, how do you handle the
query select * from table where col1='?' - did you remember not to
replace the "?" then?)

>I wonder how could this be done more cleanly.
>  
>
I think so. After all, the code to parse the command line is already there.

Try moveing the line:
        m_parsed_command="";

from PgCommand.h line 100 to SetParameterInfo, right after the line
saying "m_params.clear();". I believe this should solve the problem in a
fairly clean way. Let me know if it works.

>In the process of implementing this, I also noticed that pgoledb lacks
>support for passing date/time/timestamp values as parameters to
>postgresql (we have typeinfo::StdPGWidthInvalid for date/time types in
>s_types_type array in PgSess.cpp). For now I have implemented
>conversion to text representation, it works.
>
No, I don't like this solution. We pass arguments in binary form. The
conversion functions need to be implemented.

> Ideal solution would be
>generate different binary representations depending on postgresql
>(compile-time?) option integer_datetimes.
>  
>
We already tackled this problem for receiving arguments. Look at
COPY_timestamp code - it uses "sess->GetPgStatus(&stat,
_bstr_t("integer_datetimes") );" to find out which representation is
used by Postgres. This doesn't work on versions below 8 (for 7.4 we
guess, and we don't support earlier versions anyway).

For copyout we should do exactly the same thing.

       Shachar