Re: ADO error code 800a0c93
- From: "Stephen Howe" <stephenPOINThoweATtns-globalPOINTcom>
- Date: Fri, 5 Aug 2005 20:43:52 +0100
> Hi Stephen. Yes, it works now, without ADO Record Binding.
Right. Well the problem is in your RecordBinding code.
RecordBinding is woefully underdocumented by Microsoft and there are some
hidden gotchas.
1. If a field can be NULL, you have to have Status variables and you have to
use the field definition macros that include a Status variable. So
ADO_FIXED_LENGTH_ENTRY
ADO_NUMERIC_ENTRY
ADO_VARIABLE_LENGTH_ENTRY
ADO_VARIABLE_LENGTH_ENTRY2
The reason being is that the Status variable, on inspection (on reading)
whether that field is NULL.
If the Status variable is not NULL, you just inspect the field variable, it
was real data !!!
On updating (AddNew or Update), you can set the Status variable to adFldNull
which tells ADO that this field is to be set to NULL otherwise adFldOk.
If the Status is adFldOk, then ADO will assume the field variable is to be
written back.
2. If a field cannot be NULL, you can use the field definition macros that
don't include a Status variable.
It is optional. I use these as most of the tables I deal with don't have
NULLs. So
ADO_FIXED_LENGTH_ENTRY2
ADO_NUMERIC_ENTRY2
ADO_VARIABLE_LENGTH_ENTRY3
ADO_VARIABLE_LENGTH_ENTRY4
3. The gotchas I know about are these:
(i) There is some funny interaction between empty tables and attempting to
populate a table using AddNew and RecordBinding.
It does not always work. I have had failure on the first AddNew'ed record. I
can't remember if I got your error message number.
I think it is a problem getting the tables metadata (field types, sizes
properties etc).
The essential thing is that the derived RecordBinding class variables are
all 0 to start with - so do this in the constructor.
This guarantees it does work.
E.g. - one of my classes:
class CEventCountBind : public CADORecordBinding
{
BEGIN_ADO_BINDING(CEventCountBind)
ADO_FIXED_LENGTH_ENTRY2(1, adSmallInt, m_isISTVPanelID, FALSE)
ADO_FIXED_LENGTH_ENTRY2(2, adSmallInt, m_isISTVChanID, FALSE)
ADO_FIXED_LENGTH_ENTRY2(3, adInteger, m_iCount, FALSE)
ADO_FIXED_LENGTH_ENTRY2(4, adInteger, m_iAICount, FALSE)
END_ADO_BINDING()
public:
short m_isISTVChanID;
short m_isISTVPanelID;
int m_iCount;
int m_iAICount;
public:
// Constructor
CEventCountBind() : m_isISTVChanID(), m_isISTVPanelID(), m_iCount(),
m_iAICount() { }
};
m_isISTVChanID etc, will all be 0 to start with.
(ii) If you do have Status variables, they do need to be set to adFldNull
(if updating or inserting) otherwise always adFldOk.
If you leave them as some random value, it is this that is causing your
AddNew() problems.
AddNew() is reading the values you set (even if non-intentionally) and
acting on them in some way.
It is because of this "nuisance value", I use the non-Status RecordBinding
macros
(and makes your class smaller as each field variable does not have an
associated field status variable)
I only ever use the Status RecordBinding macros if I have to (ie.field can
be NULL) and observe rules mentioned here religiously for getting results.
It is this that Microsoft has never adequately documented.
If you Google around the Microsoft news server, searching for messages by
Roy Fine on ADO, he mentions this.
> I am a newby to ADO, and I just jumped into Visual C++ Extensions for ADO
> and hit this snag. I am wondering if ADO.NET and C# would make my life
> easier,...
Well that is your choice.
You will find that C# and ADO.NET has it's own learning curve.
Question: Is that good or bad?
Answer: Neither. Just about all Microsoft technologies have a learning
curve. C++ is heavier than most.
My advice is to heavily read Microsoft online documentation, frequent
newsgroups with more experienced programmers and read their responses (in
C++ cases, USENET comp.lang.c++ and comp.lang.c++.moderated is worth
frequenting - understand mind you they do not answer Windows questions,
Visual C++ tool questions, hardware questions - only questions related to
ISO C++ . Questions specific to VC++ should be asked on the Microsoft news
server), read whitepapers, read what is considered "Best Practice" for that
technology (deviating from "Best Practice" will usually burn you).
> except this is not a web page application. It is to run on a local
> area network only, probably for security reasons, at this time. I would
> appreciate any design considerations. Furthermore, I am using VC6 which is
> no longer supported. Should I consider using Visual Studio.NET?
I am using VC.NET 2003 (so that is VC7.1).
VC7.1 is much much more closer to standard C++ (as defined by the ISO C++
standard in 1998).
I used to use VC6 and would not move back.
Most died-in-the-wool C++ programmers want a standard-compliant compiler and
libraries (no C++ programmer wants the compiler to produce unexpected
results) and Microsoft, at last, has understood this. I think VC8 will be
even closer to standard and as soon as it is considered okay, we will
upgrade.
We produce non-NET applications with VC7.1.
They are not web-based, they are apps used internal to my company to deliver
data to our clients. They work.
Consequently we don't see any point of converting to .NET with them, there
is nothing to gain.
> Should I consider ASP.NET? I am reading around as much as I can to
understand.
It is up to you. I think if you need to make use of some technology that
..NET makes it easy to use, and a non-.NET app would be harder, then may be
should climb aboard the .NET bandwagon. But if your requirements are
undemanding, then I would prefer to develop a non-.NET app (Win32), there
is less overhead.
The technology your company is involved in should choose your tools.
On C# :
I was at the UK ACCU conference in Oxford, April 2005. Stoustrup was there.
Microsoft was there as well.
I think the consensus was that 2 years ago, C# was quite hot and "Managed
C++" (for .NET apps) was clunky. And it was.
But the past 2 years Herb Sutter and team have put a very good design effort
in using C++ for .NET and it shows.
Microsoft, internally, take C++ very seriously and compard to 2 years ago, I
think C++ would be recommended over C# for .NET apps (with VC8 that is)
They have done a very good job. With VC8, I would choose C++ over C#.
Another factor is that C++ is universal. It applies to IBM Mainframes,
Mini's, PC's, Macintoshes as well as different OS's like Linux.
And there are different C++ compilers from different vendors.
"Standard C++" is also larger than Microsoft and not controlled by Microsoft
(which some programmers might find a comforting thought)
There are more books on C++, more articles and in the long term I think the
job prospects might hav ethe edge as well.
Really C++ gives a job for life.
C# does not give you all this.
The downside of C++ is that it is an incredibly complex language.
It is a very powerful tool and like all tools can bite you if you do not
know what you are doing.
You could spend 10 years using it and still discover corners of the langauge
you did not know.
I think it has got easier over time.
But it is not a language that is friendly to newbie programmers.
C# is easier than C++, still powerful, and newbie programmers might find it
easier.
Stephen Howe
.
- References:
- ADO error code 800a0c93
- From: Michael Harvey
- Re: ADO error code 800a0c93
- From: Stephen Howe
- Re: ADO error code 800a0c93
- From: Michael Harvey
- ADO error code 800a0c93
- Prev by Date: output parameter in Access query
- Next by Date: Re: output parameter in Access query
- Previous by thread: Re: ADO error code 800a0c93
- Next by thread: Re: ADO and Jet creates error on XP Home Edition SP2
- Index(es):
Relevant Pages
|
