Article View: borland.public.cppbuilder.database.multi-tier
Article #1675Re: Another slant on the patch problem
From: John Graham
Date: Fri, 23 Jul 1999 00:00
Date: Fri, 23 Jul 1999 00:00
197 lines
8941 bytes
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-mailReferences:
<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