🚀 go-pugleaf

I fully agree with you. Quality means so much in software and to have a
patch 'wrong-the-right' is not what I expected form such and expensive
package.

Please Borland, show some signs of life on this one :-))

Regards,
Martin.

John Graham <jgraham@salts.navy.mil> escribi� en el mensaje de noticias
3796F0CB.48790F91@salts.navy.mil...
> Martin,
> Thanks for the reply.  As I stated in my original whine, I have been
following
> this thread.  I tried  Mark's solution and it did not work for me.  It's
> possible that I didn't catch all of the references to "IProviderPtr", but
I
> went through all of the generated source code a couple of times.
>
> Mark's procedure is not an answer nor is it a solution; rather it is a
> workaround - not the kind of necessity one expects when one spends a
> considerable amount of money for a development platform, and certainly not
what
> I expect based on my experience with BCB.  I have been using this platform
> since its inception. I do not expect a commercial package to be bug free,
> however, I do expect it to work.  And I expect a factory created patch to
not
> cause problems that did not exist prior to the update.
>
> The facts are these: everything works as documented with the original
install;
> things don't work when the patch is installed.
>
> I have repeated this problem using the EmpEdit example supplied.  I simply
> compiled and linked both the app server and client projects with the
updated
> version of BCB4 and it worked flawlessly running the server locally as
well as
> on one of our remote NT Servers.
>
> I then built a new app sever being careful to duplicate the lashup in the
> original and compiled and linked it.  I registered everything and came up
with
> the same "Interface Not Supported" error pointing to utilcls.h when the
client
> connected to the server as I experienced with my own application.
>
> What I would like to see is a response from Team B or Borland
acknowledging
> that there is a problem and that they're working on it, or some kind of
> additional documentation which will show me where I have gone astray.
>
> These are your ( and everyone else's ) federal tax dollars that are being
> wasted while I try to get this project of mine off the dime.  Despite
rumor to
> the contrary, there are those public mammary types among us who try to
give
> good value for the bucks spent.
>
> Regards,
> John
>
> Martin Hart wrote:
>
> > The answer was given a week or so ago. Here is the answer.
> >
> > Mark Johnson said:
> >
> > -----------------------------------------------
> > I had this same problem.  The cause is the new tlb editor creates code
with
> > a type IProviderPtr replacing  what used to be IProvider* in the
generated
> > code.  If you go through all the generated source and replace
IProviderPtr
> > with IProvider* the remote data modules will now work.  Hope this helps.
> >
> > Mark Johnson
> > -----------------------------------------------
> >
> > Panagiotis L. Staikos <pstaiko@ekt.gr> escribi� en el mensaje de
noticias
> > 37805D31.B7AF2946@ekt.gr...
> > > I have add at server Side (Remote DataModule)
> > > a TQuery Component and a TProvider(TProvider or TDataSetProvider)
> > > Component.
> > > I export the TProvider Component and it's DataSet property points to
> > > TQuery. The TQuery component has a SQL Statement.
> > > From Client Side i have a MIDAS, ClientDataset, DataSource, DBGrid
> > > Components.
> > > While i am connecting with my Server,when  i change the active
property
> > > of The ClientDataSet to true
> > > (ClientDataSet Provider Property points to the Above TProvider)
> > > i get the Error :
> > > 'src->QueryInterface(GetIID(),(LPVOID*)(&intf))': No such interface
> > > supported
> > > @ C:\Program Files\Borland\CBuilder4\invlude\vcl\utilcls.h/2014
> > > Press [Y]es to terminate, [N]o to continue and [C]ancel to Debug.
> > >
> > > All the Providers from the server are shown in the drop-down list in
the
> > > Provider property
> > > of the ClientDataSet Component!!!
> > >
> > > Prior the patch#1 i did't have any problem....
> > > More spesific the code that i use it works with C++Builder3, and
> > > C++Builder4 withou the path#1!!!
> > > How is the right connection between ClientDataSet and a Provider?
> > >
> > > I don't understand this error beacuse i think that all is ok.....
> > > (This problem was stop me since a week...)
> > > May i have a answer to this problem?
> > >
> > > Thanks. Panagiotis Staikos from Greece.
> > >
> > >
> > >
> >
> > John Graham <jgraham@salts.navy.mil> escribi� en el mensaje de noticias
> > 3791FB86.923BE652@salts.navy.mil...
> > > I converted a medium sized 2 tier app. into a 3 tier app using BCB 4
as
> > > installed from the factory.  The app. server contains a number of
TQuery
> > >
> > > objects, and the client app. contains representative TClientDataSet
> > > objects.
> > >
> > > When compiled and linked, both client and server apps. worked great
> > > together.  However, when I installed the patch everything went south.
I
> > >
> > > have followed the threads in the forum about this problem, and have
> > > completely built a new server app. which runs and does its thing with
> > > the MS SQL database.  I have also recompiled the client app. The DCOM
> > > object fires up the app server which connects to the database
normally.
> > > But when the client attempts to trigger one of the TQuery objects ( to
> > > find a record in a table ), I get a "No such interface supported"
error
> > > and everything stops.
> > >
> > > The error is being caused by the call to the QueryInterface() function
> > > in line 2014 of the UTILCLS.H header file ( \include\vcl ), which is
one
> > >
> > > of the files updated by the patch.
> > >
> > > I know if I uninstall BCB and reinstall it from the CD that the apps.
> > > will work.  I have done that once already.  But while both apps worked
> > > together when they were located on the same machine, I was unable to
get
> > >
> > > the client to work with the app server with the server installed and
> > > running on one of our other servers ( an IBM NetFinity using NT Server
> > > as its OS ).  The client found and fired up the app server, but I was
> > > getting an OLE error number 80070105.  Yes, all required DLLs were
> > > installed and registered on the NF server, and the client's DCOM
> > > connection was able to connect.
> > >
> > > So I reinstalled the patch and landed square in the middle of the
> > > problem
> > > described in the first paragraphs above.
> > >
> > > Does anyone know what's going on?  I don't have any hair left to pull
> > > out!
> > >
> > > Regards,
> > > John
> > >
> > >
>