🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: borland.public.cppbuilder.database.multi-tier
Article #1675

Re: Another slant on the patch problem

#1675
From: John Graham
Date: Fri, 23 Jul 1999 00:00
197 lines
8941 bytes
Thanks to you both for the replies.  Mark, I guess you ran into a level one
service "engineer" who may be operating with a "Don't confuse me with the facts,
my mind is made up" philosophy.  A variation of this is the "It runs ok on my
machine" philosophy.

Frankly I'm tired of dealing with so called customer service types who react as
if I'm an idiot.  I may be ignorant in certain areas, but I'm not stupid, and I
don't make phone calls for the sake of having someone to talk to.  Ah well.

I did the same thing the "engineer" did and found that when I rebuilt the app.
server that it bombed when the client tried to connect.  Ipso facto or some
other Latin phrase - there IS a problem.

Meanwhile, I uninstalled the patched version and reinstalled from the CD.  My
application now runs as advertised - at least with the app. server running in
local memory.  I haven't tested it on one of our NT Servers yet; I need some
success in my life to prepare me for the next failure.

Pip, Pip,
John


Martin Hart wrote:

> 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
> > > >
> > > >
> >
Technical Details
Message-ID: <379880AC.1A38C2FD@salts.navy.mil>
Path: arc1-ca.pugleaf.net!unknown!not-for-mail
References: <3791FB86.923BE652@salts.navy.mil> <7n6buq$la622@forums.borland.com> <3796F0CB.48790F91@salts.navy.mil> <7n91d3$nm726@forums.borland.com>

Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII
X-Google-Thread: fcd2b,e64518dbee1d18e6
X-Google-Attributes: gidfcd2b,public
From: John Graham <jgraham@salts.navy.mil>
Subject: Re: Another slant on the patch problem
Date: 1999/07/23
Message-ID: <379880AC.1A38C2FD@salts.navy.mil>
X-Deja-AN: 504419708
Content-Transfer-Encoding: 8bit
References: <3791FB86.923BE652@salts.navy.mil> <7n6buq$la622@forums.borland.com> <3796F0CB.48790F91@salts.navy.mil> <7n91d3$nm726@forums.borland.com>
To: Martin Hart <memorysoft@infotelecom.es>
X-Accept-Language: en
Content-Type: text/plain; charset=iso-8859-1
Organization: U. S. Navy SALTS Project
Mime-Version: 1.0
Newsgroups: borland.public.cppbuilder.database.multi-tier