Przemysław Czerpak wrote:
BTW I'm still waiting for verification of reported RDDADO problems
with current HBWIN OLE code. Can some MS-Windows users check it?
It is not in current SVN, I copied adordd.prg, and adordd.ch and
tests\access1.prg from an old backup:
* $Id: adordd.prg 10183
BTW I'm still waiting for verification of reported RDDADO problems
with current HBWIN OLE code. Can some MS-Windows users check it?
It is not in current SVN, I copied adordd.prg, and adordd.ch and
tests\access1.prg from an old backup:
* $Id: adordd.prg 10183 2009-02-05 09:21:52Z vszakats
Viktor Szakáts wrote:
Can you try with the copy in 'examples/rddado' and tests
under 'tests'.
OK, got them. access1.prg fails with :
Error OLE/3012 Argument error: OPEN (DOS Error -2147352567)
Called from WIN_OLEAUTO:OPEN(0)
If I replace this line:
USE test.mdb VIA ADORDD TABLE Tabla1
Hi Alex,
USE test.mdb VIA ADORDD TABLE Tabla1
with:
USE xbrtest.mdb VIA ADORDD TABLE Customer
it works. Perhaps test.mdb is broken?
Could be. Or it simply doesn't find it. But your
next example suggest that it's the former.
BTW: broken, I've fixed this file at least once
14:19
À : Harbour Project Main Developer List.
Objet : Re: [Harbour] Problem in OLE implementation
Hi Alex,
USE test.mdb VIA ADORDD TABLE Tabla1
with:
USE xbrtest.mdb VIA ADORDD TABLE Customer
it works. Perhaps test.mdb is broken?
Could be. Or it simply doesn't find it. But your
On Tue, 01 Dec 2009, J. Lefebvre wrote:
Hi,
Hu, not sure it is really related to a problem with ADORDD (see dos
error).
I have exactly the same error trying to access Crystal report runtime XI.
Error occurred at: 01/12/2009, 14:26:32
Error description: (DOS Error -2147352567)
Hi,
Error OLE/3012 Argument error: OPEN (DOS Error -2147352567)
Called from WIN_OLEAUTO:OPEN(0)
Called from ADO_OPEN(312)
Called from DBUSEAREA(0)
Called from MAIN(12)
It would be nice to have some idea about how error subcode sould be
used. 3012 does not say much about the exact place of
Error OLE/3012 Argument error: OPEN (DOS Error -2147352567)
Called from WIN_OLEAUTO:OPEN(0)
Called from ADO_OPEN(312)
Called from DBUSEAREA(0)
Called from MAIN(12)
It would be nice to have some idea about how error subcode sould be used.
3012 does not say much about the exact place of
-Original Message-
From: Alex Strickland [mailto:s...@mweb.co.za]
Sent: Tuesday, December 01, 2009 1:22 PM
To: Harbour Project Main Developer List.
Subject: Re: [Harbour] Problem in OLE implementation
...
REQUEST ADORDD
function Main()
USE xbrtest.mdb VIA ADORDD TABLE Customer
-
De : harbour-boun...@harbour-project.org
[mailto:harbour-boun...@harbour-project.org] De la part de Przemyslaw Czerpak
Envoyé : mardi 1 décembre 2009 15:10
À : Harbour Project Main Developer List.
Objet : Re: RE: [Harbour] Problem in OLE implementation
On Tue, 01 Dec 2009, J. Lefebvre wrote
J. Lefebvre wrote:
I will continue to investigate,
Perhaps this may help:
http://www.microsoft.com/downloads/details.aspx?familyid=5233b70d-d9b2-4cb5-aeb6-45664be858b6displaylang=en#QuickInfoContainer
it is OleView.exe which is quite useful for seeing what is behind the scenes.
Regards
On Tue, 01 Dec 2009, Szak�ts Viktor wrote:
Hi,
USE test.mdb VIA ADORDD TABLE Tabla1
with:
USE xbrtest.mdb VIA ADORDD TABLE Customer
it works. Perhaps test.mdb is broken?
Could be. Or it simply doesn't find it. But your
next example suggest that it's the former.
BTW: broken, I've
Przemysław Czerpak wrote:
Alex can you try to add at the beginning of rddado/tests/access2.prg:
FIELD FIRST
and change the line 33 from:
locate for TEST2-First = Lara
to:
locate for First = Lara
and then repeat the test?
Yes, this works and writes .T. to the console.
Regards
Alex
Thank you. So there still seem to be some things broken
after whichever update, my suspect is still the xhb sync job.
Looking at the ChangeLog and SVN repository I haven't found even
single xhb sync commit.
2008-09-12 00:53 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
*
On Tue, 01 Dec 2009, Alex Strickland wrote:
Alex can you try to add at the beginning of rddado/tests/access2.prg:
FIELD FIRST
and change the line 33 from:
locate for TEST2-First = Lara
to:
locate for First = Lara
and then repeat the test?
Yes, this works and writes .T. to the
On Tue, 01 Dec 2009, Szak�ts Viktor wrote:
2008-09-12 00:53 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
* contrib/rddado/adordd.prg
* contrib/rddado/adordd.ch
* Merged changes from xhb.
Some hbusrrdd.ch values seem to be missing from Harbour,
related features will be
On Tue, 01 Dec 2009, Szak�ts Viktor wrote:
2008-09-12 00:53 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
* contrib/rddado/adordd.prg
* contrib/rddado/adordd.ch
* Merged changes from xhb.
Some hbusrrdd.ch values seem to be missing from Harbour,
related features will be
I see no point in moving it back to contrib until someone
takes a plunge into this and known problems get fixed.
So far I haven't seen any confirmed error in ADORDD code
so I have no idea what we can fix.
Of course this RDD should be greatly improved yet and some
missing functionality
On Tue, 01 Dec 2009, J. Lefebvre wrote:
Hi,
You could be right, but ...
1) This code is not really new, and I had in mind it was working when I
tested it some month ago (99% sure) ...
2) The same call in visual Basic work fine on the same OLE object ...
I will continue to investigate,
I
On Tue, 01 Dec 2009, Szak�ts Viktor wrote:
Hi,
Of course this RDD should be greatly improved yet and some
missing functionality added. Also if someone has time then
function like SQLTranslate() should be rewritten from scratch
to be real xbase to SQL expressions translator. Not a small
Just had time to read this bit, well, I couldn't have
said it better. Probably many other improvements could
be made on that driver. F.e. for me thos HB_ADORDD*()
functions look a little strange in an RDD. They're
needed to setup connection, and connection is stored
in thread static
On Sat, 28 Nov 2009, Szak�ts Viktor wrote:
Hi,
documented RTE which can substitute result so it can be easy
caught by user and if necessary he can set his own preferable
value for such unknown OLE variant.
What it group opinion here?
+1 to Nil (if I have a voice)
I also prefer NIL
Hi,
Hi,
Przemysław Czerpak wrote:
BTW in MS documentation dimensions are stored in 'unsigned int' instead
of 'int'. Maybe we should follow it?
So, it's long, not unsigned int. But the most strange thing is that
SafeArrayGetDim return HRESULT. Sounds like a handler, and this
stopped me from
On Mon, 30 Nov 2009, Mindaugas Kavaliauskas wrote:
Hi,
Yes, perhaps type should be unsigned int. HRESULT is a general
return value, since MS uses type casting anythere.
OK, I'll update it.
2009-11-28 13:27 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
*
Hi,
Przemysław Czerpak wrote:
I'm not very familiar with OLE code so maybe I'm wrong but I do not see
any reason why it has to be the same pointer. I can imagine implementation
which will use different pointers so I would like to keep the code clean
and if I called punkVal-QueryInterface()
On Fri, 27 Nov 2009, Alex Strickland wrote:
Hi,
I have an OLE dll that I am trying to use. I think it returns a
safearray of IUnknown.
To understand a bit better I put the following 3 debug lines in olecore.c:
void hb_oleVariantToItem( PHB_ITEM pItem, VARIANT* pVariant )
{
char debug[ 100
-Original Message-
From: Przemysław Czerpak [mailto:dru...@acn.waw.pl]
Sent: Friday, November 27, 2009 6:54 PM
To: Harbour Project Main Developer List.
Subject: Re: [Harbour] Problem in OLE implementation
On Fri, 27 Nov 2009, Alex Strickland wrote:
Hi,
[...]
documented RTE which can
Hi,
[...]
documented RTE which can substitute result so it can be easy
caught by user and if necessary he can set his own preferable
value for such unknown OLE variant.
What it group opinion here?
+1 to Nil (if I have a voice)
I also prefer NIL (or some other distinctive error
value)
On Fri, 27 Nov 2009, Mindaugas Kavaliauskas wrote:
Hi,
BTW in MS documentation dimensions are stored in 'unsigned int' instead
of 'int'. Maybe we should follow it?
MSDN writes:
HRESULT SafeArrayGetDim( SAFEARRAY FAR* psa );
BCC wtypes.h has:
#ifndef _HRESULT_DEFINED
#define
Hi
Przemysław Czerpak wrote:
BTW I have question about code in axcore.c.
In function __AXDOVERB() we have call to QueryInterface() but without
call to Release(). Shouldn't we add at axcore.c[213]:
HB_VTBL( lpOleObject )-Release( HB_THIS( lpOleObject ) );
???
Yes, good catch.
On Sat, 28 Nov 2009, Pritpal Bedi wrote:
Hi,
BTW I have question about code in axcore.c.
In function __AXDOVERB() we have call to QueryInterface() but without
call to Release(). Shouldn't we add at axcore.c[213]:
HB_VTBL( lpOleObject )-Release( HB_THIS( lpOleObject ) );
???
Yes,
-Messaggio Originale-
Da: Przemysław Czerpak dru...@acn.waw.pl
A: Harbour Project Main Developer List. harbour@harbour-project.org
Data invio: venerdì 27 novembre 2009 3.57
Oggetto: Re: [Harbour] Problem in OLE implementation
Hi,
I've just check that there is also bad typo which
Hi Mindaugas, Przemyslaw
I have an OLE dll that I am trying to use. I think it returns a safearray of
IUnknown.
To understand a bit better I put the following 3 debug lines in olecore.c:
void hb_oleVariantToItem( PHB_ITEM pItem, VARIANT* pVariant )
{
char debug[ 100 ];
if(
Enrico Maria Giordano wrote:
Works fine now, thank you all.
I tested it as well, and it works great.
Regards
Alex
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
Alex Strickland wrote:
Is it possible to add support for this?
It may be better to replace the lines at the end of hb_oleVariantToItem
default:
hb_itemClear( pItem );
with a run time error?
Regards
Alex
___
Harbour mailing list
On Fri, 27 Nov 2009, Alex Strickland wrote:
Hi,
It may be better to replace the lines at the end of hb_oleVariantToItem
default:
hb_itemClear( pItem );
with a run time error?
It should be real OLE users decision. Do you prefer RT error when unknown
OLE item is received or
On Fri, 27 Nov 2009, Alex Strickland wrote:
Hi,
Enrico Maria Giordano wrote:
Works fine now, thank you all.
I tested it as well, and it works great.
It's also possible that this modification resolved some of ADO RDD
problems. Users interested in this RDD should repeat their tests.
best
On Fri, 27 Nov 2009, Mindaugas Kavaliauskas wrote:
Enrico Maria Giordano wrote:
In the following sample, GetRows() method returns NIL (correctly
returns an array using xHarbour):
Current Harbour OLE implementation supports only one dimensional
array. I'll try to add support for
On Fri, 27 Nov 2009, Przemysław Czerpak wrote:
I've just check that there is also bad typo which causes that it does
not convert even one dimensional VT_ARRAYS to Harbour items.
I'll commit fix in a while so if this code needs only one dimensional
arrays the it may be enough.
Please test.
On Fri, 27 Nov 2009, Przemysław Czerpak wrote:
Hi
I found two:
if( lFrom = lTo ) // cause hb_itemClear() fall through
and
hb_arrayGetItemPtr( pItem, ul++ ) (or ul = 0;) // GPF
I haven't seen the second one.
I've not replicated it.
yes, good job. Again thank you very much.
But
Hi,
Przemysław Czerpak wrote:
yes, good job. Again thank you very much.
I've also looked at SafeArrayToArray() function from xHarbour
win32ole.prg, but after 10 seconds I've understood it's better not to
look at this, because I can start to replicate it. So, that's the reason
why
Hi,
But we have new one. Looks that
VariantInit( vItem );
at line 517 is missing.
I know, but you are faster this time :)
Regards,
Mindaugas
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
On Fri, 27 Nov 2009, Mindaugas Kavaliauskas wrote:
Hi,
I've also looked at SafeArrayToArray() function from xHarbour
win32ole.prg, but after 10 seconds I've understood it's better not
to look at this, because I can start to replicate it. So, that's the
reason why hb_oleSafeArrayToItem() is
Hi,
Przemysław Czerpak wrote:
Yes it's really nice though it probably can be even simpler without
recursion.
This code allocates memory for index array using hb_xgrab() and needs
recursion only for allocating dynamically lFrom and lTo on C stack.
It means that it should be enough to allocate
In the following sample, GetRows() method returns NIL (correctly returns an
array using xHarbour):
function main()
local oCn, oRs, aRows
oCn := CreateObject( 'ADODB.Connection' )
oCn:ConnectionString := Provider=Microsoft.Jet.OLEDB.4.0;Data
Hi,
Enrico Maria Giordano wrote:
In the following sample, GetRows() method returns NIL (correctly returns
an array using xHarbour):
Can you provide some file to be tested using the following sample? In my
case sample does not work because e:\fwharbour\samples\xbrtest.mdb does
not exist.
46 matches
Mail list logo