BDE Error 10756 : $2A04 : Operation not applicable.
Clive Gifford
("Operation not applicable") can be caused by?
We've had this appear a number of times recently with applications accessing
a shared database on a machine running NT4. Finally we ended up with a table
being damaged (updated) even though all known code was only reading data
from it.
On a related topic (finding and fixing damaged tables), anybody got any
comments about reliability, etc., of the "ChimneySweep" product?
(http://www.sundialservices.com/products/chimneysweep/index.htm)
Thanks
Clive.
Arnie Mauer
getting the same error code - whose description doesn't help at all.
We're running against W2K servers and an Oracle DB so our situation
isn't the same. I put the problem into Borland Bronze (single incident)
support and after a week, they're refunding my money with no other
explanation.
If we come up with anything, I'll let you know.
- Arnie
"Clive Gifford" <clive_...@hotmail.com> wrote in message
news:3b09d4d4_1@dnews...
Clive Gifford
I should have provided a bit more information in my first post.
The NT box is running a server application (accessing many Paradox 4 tables
through the BDE, scattered across multiple directories on the same machine).
A client application (typically 5-20 instances running concurrently) connect
through telnet (SeattleLab's SLnet) and a proprietary comms protocol.
However other users (less frequently) can also be accessing the same tables
though network shares, or from the desktop, etc.
One thing I did not have turned on was LOCAL SHARE on the server. I've
turned that on now just in case that contributed. (We also have a few 16 bit
tools built on top of the old Paradox Engine that are very occasionally used
on that machine also, although not at the times these problems happened as
far as I know.)
We also found that stopping all running BDE apps and deleting the
PDOXUSRS.NET file seemed to clear the problem. Otherwise, once the error had
appeared, all subsequent attempts to use the BDE appeared to produce the
same error message when the first attempt was made to access a table. i.e.
Although we don't really know what caused the first instance, after that it
seemed that any operation on any table by any user generated the same error.
(We weren't able to spend a lot of time trying different scenarios though).
Clive.
"Arnie Mauer" <ar...@marketexpert.com> wrote in message
news:3b0a4c28_1@dnews...
John Pierce
Arnie Mauer wrote:
> FYI - You're not alone. We and a number of other people in the forum are
> getting the same error code - whose description doesn't help at all.
> >
If you can, have a look at Direct Oracle Access.
John Pierce
Nan Jiang
application connect to oracle7.3 for sco. At first software environment was
not setup by me and it run well. When I distributed the program to other
machine, this message appeared. I don't know why, so reinstall the win98,
c++builder5 and oracle client, we had really this problem. I solved this
problem through deleted this two statements
DataModule1->Query1->ParamByName("h_fmoney")->AsFloat=MedtMoney->Text.ToDoub
le();
DataModule1->Query1->ParamByName("h_bz")->AsString=bz;
and modified sql statement to
DataModule1->Query1->SQL->Add("select HM,KHZJHM,ZH,CKJE,CUNQCHN,DZ from
D_DQCXFHZ,D_CUNQI \
where D_DQCXFHZ.CQ=D_CUNQI.CUNQID and CKJE>"\
+MedtMoney->Text+" and LL>0.01 and BZ="+bz+" order by CKJE
desc");
Jiang Nan
Arnie Mauer
for (insert) performance, the OCI API. Our "batch" apps typically
deal with very large amounts of data and DOA works well there. The
interactive client typically makes much more focused SELECTS and
doesn't use LOBs so we can get away with BDE.
We were trying to stay as DB independent as possible, hence the BDE.
I curse the day I ran across it - and the SOB that put it together.
"John Pierce" <jpi...@healthplanning.com> wrote in message
news:3B0AE194...@healthplanning.com...
John Pierce
Arnie Mauer wrote:
>
> We were trying to stay as DB independent as possible, hence the BDE.
> I curse the day I ran across it - and the SOB that put it together.
I never thought I'd defend the BDE, but it was a great thing in its time.
But making it work with SQL back ends is the programming equivalent of
shoehorning. I gave up on the idea of working with multiple servers, so we
require Oracle. But we have the luxury of being able to do that.
Regards,
John
Jerry Bloomfield (TeamB)
<clive_...@hotmail.com> wrote:
>We also found that stopping all running BDE apps and deleting the
>PDOXUSRS.NET file seemed to clear the problem. Otherwise, once the error had
>appeared, all subsequent attempts to use the BDE appeared to produce the
>same error message when the first attempt was made to access a table. i.e.
>Although we don't really know what caused the first instance, after that it
>seemed that any operation on any table by any user generated the same error.
>(We weren't able to spend a lot of time trying different scenarios though).
I have seen one case which I believe produces this error, and it is
possible that your scenario is quite similar to the one I have seen...
If you start/stop BDE applications in rapid succession, with the potential
for a large number of these BDE based applications to be
starting/running/stopping simultaneously, the BDE does become "confused"
and does not properly initialize or shutdown a session. After enough of
these, the BDE gets to the point where it can not properly initialize a new
session and any attempt to launch a BDE application results in the "$2A04"
error.
I have documented that the "known issue" (a BDE Error reported on Oct.
1996) from the BDEREADME.TXT file:
BDE & CGI Applications [43890][12552]
-----------------------------------------------------------
In CGI applications, if the volume of BDE initializations
is high enough (varies with circumstances), error
"Operation not applicable occurs." Only known work around is
to use ISAPI instead of CGI.
also happens in other non-CGI applications which have the same "high volume
BDE initializations". I have not gotten any response from my report nearly
2 years ago... In my case, I could not use ISAPI to get around my
non-CGI problem, so I had to resort to using the ODBC API directly. As a
result, there is a C++ class which I have uploaded to CodeCentral which we
used to get around this problem for us. I do not know if you can use that
or not, but you are welcome to try...
Jerry Bloomfield (TeamB)
--
http://www.teamb.com Jers...@wwa.com
Please do *NOT* send private e-mail without prior permission (my anti-spam
filters will probably just delete it anyway <g>)
Arnie Mauer
Where is this C++ class?. I saw a DLL that's supposed to fix the problem
in the BDE utilities but it was for BDE 4.51. We're using 5.1.1.
Thanks,
-Arnie
"Jerry Bloomfield (TeamB)" <Jers...@wwa.com> wrote in message
news:hhg3htgf4k2rmvaot...@4ax.com...
Jerry Bloomfield (TeamB)
wrote:
>Where is this C++ class?. I saw a DLL that's supposed to fix the problem
>in the BDE utilities but it was for BDE 4.51. We're using 5.1.1.
It is available for download from Code Central on the Borland Community web
site. From there do a search on my name and you should find two entries.
One will be the source for an application to dynamically create ODBC DSN's,
as well as creating, compacting, & repairing MS MDB files via ODBC. The
other is the Todbc class I referenced in my last post. I believe that the
ODBC class is the lower of the two numbers, but I do not remember right
now, and I do not have an active connection to go find the exact link for
you...
Ricardo Tapia
I am other in your list I'm using Delphi and BDE on my web
and every day whe have to reset the server.
when we change the value of MEMSIZE form 16 to 256,
the problem was daily and not 3 times on the day
But the best solution for us was changing to dreamweaver ultradev and work with asp
Regards