|
In the SQLExecute(hstmt) the hstmt is being passed to the Oracle ODBC 8i driver as an SQL_CHAR which is limited to 255 charaters. So if you have a large table requiring say 300-500 characters then your inisert or select statement will fail. Can anyone tell me if there is a way to fix this limitation? The Visual C++ side is using a CString object so it has more then enough size to handle the large statement. The problem is definately on the ODBC side. Any help on this matter would be greatly appreciated.
Thanks,
Charlie
Everything is Free... Until You Have to Pay for it...
Platforms Windows 2000/XP Professional using Visual C++ 6.0
|
|
|
|
|
Charlie Curtis wrote: ...as an SQL_CHAR which is limited to 255 charaters...
Where do you find this limitation documented? The text length parameter passed to
SQLPrepare()/SQLExecDirect()/etc. is a long integer - 32 bits.
Mark
|
|
|
|
|
Hi Mark,
Haven't really found any documentation per say I am going by the fact that when I trace through the code and I look at the string being passed to SQLExecute(hstmt) it is in fact limited to 255 characters. I have tried both the SQLPrepare() and SQLExecDirect() funtions as well, but always the same the string passed is 255 characters. So any further help here would be appreciated.
Thanks for replying to this message,
Charlie
Everything is Free... Until You Have to Pay for it...
Platforms Windows 2000/XP Professional using Visual C++ 6.0
|
|
|
|
|
Charlie Curtis wrote: when I trace through the code and I look at the string being passed to SQLExecute(hstmt) it is in fact limited to 255 characters
The string being passed or are you tracing into SQLExecute() and seeing it being truncated??
Are you passing the correct string length or SQL_NTS for the text length parameter?
Mark
|
|
|
|
|
Hey Mark,
I am passing SQL_NTS is that my problem?
Thanks,
Charlie
Everything is Free... Until You Have to Pay for it...
Platforms Windows 2000/XP Professional using Visual C++ 6.0
|
|
|
|
|
Not unless there's a _T('\0') at index 255 in your buffer 
So the string is already truncated before the call to ODBC? If put a breakpoint at the call what's
in the string?
Mark
|
|
|
|
|
Yes Sir that is correct it is being truncated prior to the SQLExecute. It has 255 charaters of the string in it. It has 253 readable characters and I am assuming the \0 at the end. However, there is no reason for it to truncate at that point as it is a CString object. So it is reall freaking me out that it is doing that...
Charlie
Everything is Free... Until You Have to Pay for it...
Platforms Windows 2000/XP Professional using Visual C++ 6.0
|
|
|
|
|
hmm Can you show the code used to construct the string?
If you do this do you get more than 255 chars in your string?
CString str(_T(""));
for (int i = 0; i < 16; ++i)
{
str += _T("0123456789012345");
}
str += _T("This is past 256 chars");
|
|
|
|
|
No I get the same a truncated string ending at 901. I even created a brand new project to see if maybe it was something specific to the project I am workingon, but it truncates in the new project the same... Not getting it. I wouldn't think it would, but maybe you know better then I. Could it have something to do with this computer having a 64 bit processor? Just grasping at straws now...
Everything is Free... Until You Have to Pay for it...
Platforms Windows 2000/XP Professional using Visual C++ 6.0
|
|
|
|
|
Charlie Curtis wrote: No I get the same a truncated string ending at 901
Well I am clueless at this point
It's not ODBC if that helps any 
I don't know whether or not there's issues with CString in 64-bit.
Here's an article about a CString-like implementation that maybe you can use
CString-clone Using Standard C++[^]
If I come up with something I'll let you know!
Mark
|
|
|
|
|
OK, I appreciate your time, and if I come up with what it is I will try to remember to let you know what it was...
Charlie
Everything is Free... Until You Have to Pay for it...
Platforms Windows 2000/XP Professional using Visual C++ 6.0
|
|
|
|
|
I had similar problem before but with a different driver and different database using Visual C++ 6.0.
Found out that the debugging facilities cannot show more than 256 char not the driver. It was a problem with the sql statement after the 256th char.
Try 'MessageBox'ing the sql statement before and after execution. See if you get a truncated text. And check ur sql syntax there.
|
|
|
|
|
Hi Onn,
Thank you very much for your reply! I did the MessageBox thing and sure enough you are right it shows the whole statement! That helps me very much as now I can find out what is wrong with the statement.
For anyone reading this and wondering what the actual problem turned out to be; Well it turned out that it was in the formatting of the statement itself. If you miss one little quote or comma then there is hell to pay! As for the truncated string Onn was absolutley correct. The full string is being passed and the truncating has to do with the debugger only being able to show the first 255 characters.
Hope this helps anyone else who might have run up against this!
I'm sure most everyone knows, but just in case someone is new it might help! If you can't get the code working in your c/c++, Visual c++ code it helps me alot in many cases to work with the statements using SQLPlus and when I get it to work there it maost likely translates right over to my code.
Thank You Very Much!
Charlie
-- modified at 23:40 Thursday 2nd November, 2006
Everything is Free... Until You Have to Pay for it...
Platforms Windows 2000/XP Professional using Visual C++ 6.0
|
|
|
|
|
Okay, I'l try my best to describe the problem at hand. This is what the relations looks like:
CQuad :
implements CNodeInterface
CNodeInterface :
knows of CScene
CScene:
knows of CQuad
knows of CNodeInterface
I have some nasty circular dependency here, I know, but I can't seem to design it away. Anyway, the problem is that CNodeInterface needs to be defined before CQuad gets defined, however no matter how I tinker I can't seem to get this to happen. With forward declarations I still get errors in CQuad that CNodeInterface is undefined. Part of the problem is that I don't even know what decides which gets defined first when there's circular dependency. I'm using Visual Studio 2005.
Any help appreciated.
|
|
|
|
|
A forward declaration isn't going to work if you are calling functions from within that class. Did you try adding an extern forward declaration?
|
|
|
|
|
Yupp, and I'm still geting the same compilation error 
|
|
|
|
|
If you post some of the relevant code, someone may be able to offer you an alternative design. Circular dependencies should be avoided, and doing so will also avoid your compilation problem.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
CScene is a scene graph. CNodeInterface is an abstract class that defines the interface for nodes in the scene graph. CQuad in turn is a type of node that lies at the top of the scene graph and creates a quad tree for sub nodes that later on implements CNodeInterface lies in.
|
|
|
|
|
You need some design changes. We don't have enough information yet to help much with that.
led mike
|
|
|
|
|
Okay, I'l try my best to describe the problem more precisely. Before I go into further details, this is an implementation of a scene graph holding a quad tree, something used in graphics programming in order to arrange elements in space to avoid sending unnecesary data to the graphics card.
First of all there's CScene, which represents the scene graph. CScene holds a tree of nodes and functionality for inserting in that tree and manipulating it. Since this tree can hold a lot of diffrent types of nodes, I need to just define a very loose interface for the minimum required functionality of a node that needs to be implemented ( such as Update, Render, AddChild etc ). That interface is called CNodeInterface. When CScene is created it will create the upper elements of the tree with CQuads, this is to create the quad tree. This is how it could look for example:
ROOT
|
|---Quad 1
| |
| |---Quad 1.1
| |
| |---Player
| |
| |---Sword
|
|---Quad 2
|---Quad 3
|---Quad 4
|
In order to save space I've left out nodes under Quad 2, 3 and 4 as well as 3 sub quads under Quad 1. Player and Sword implements CNodeInterface.
Thankful for any help
|
|
|
|
|
From your desrciption it sounds more like you need a polymorphic style layout rather than cyclic. Try deriving your classes from a common base class, then pass a pointer to the base class around rather than the derived classes. Again, without seeing exactly what you are trying to do it's kinda hard to give you advice.
|
|
|
|
|
Ylis wrote: First of all there's CScene, which represents the scene graph
That does not provide enough context to understand the purpose/roll/responsibility of CScene
Ylis wrote: I need to just define a very loose interface for the minimum required functionality of a node that needs to be implemented ( such as Update, Render, AddChild etc )
It does not seem that AddChild belongs in the same type as Update and Render. Your QuadNode should likely be a template container then you might have an interface containing the Update and Render methods and then you would implement QuadNode root node (your tree) with the interface as the template parameter.
interface ISceneEntitiy
void Render( canvas or device context etc)
void Update(....)
tempate <class t=""> class QuadNode
{
// implements AddChild, Remove, and accessors, iterators for traversing etc.
}
then somewhere (we don't have enough information to know where)
QuadNode<isceneentity> _rootNode;
then you Player and Sword implement the ISceneEntity interface
Then you likely need some Creational Pattern to generate (populate) the tree. Then if the tree is mutable you likely need some Manager to contain the logic of change to the tree.
There might be much more than this but again we don't have enough information to go on.
led mike
|
|
|
|
|
This is probably a stupid question, but is there any sort of time restriction on processing windows messages? In particualar the WM_PAINT and related messages?
I'm seeing some really strange behaviour with my window. I have 3 skinned static controls, each is an instance of exactly the same class. All message processing and function calls are identical. The only difference is the size and position. The control at the bottom of the window is failing to recieve WM_PAINT message while the window is being resized. Or I should say, failes to recieve messages when the main window is of a certain height.
here is the output from spy++
<00865> 0038085C S WM_WINDOWPOSCHANGING lpwp:0012E3B0
<00866> 0038085C R WM_WINDOWPOSCHANGING
<00867> 0038085C S WM_CHILDACTIVATE
<00868> 0038085C R WM_CHILDACTIVATE
<00869> 0038085C S WM_WINDOWPOSCHANGED lpwp:0012E3B0
<00870> 0038085C S WM_MOVE xPos:14 yPos:105
<00871> 0038085C R WM_MOVE
<00872> 0038085C R WM_WINDOWPOSCHANGED
<00873> 0038085C S WM_WINDOWPOSCHANGING lpwp:0012E3B0
<00874> 0038085C R WM_WINDOWPOSCHANGING
<00875> 0038085C S WM_CHILDACTIVATE
<00876> 0038085C R WM_CHILDACTIVATE
<00877> 0038085C S WM_WINDOWPOSCHANGED lpwp:0012E3B0
<00878> 0038085C S WM_MOVE xPos:14 yPos:104
<00879> 0038085C R WM_MOVE
<00880> 0038085C R WM_WINDOWPOSCHANGED
<00881> 0038085C S WM_WINDOWPOSCHANGING lpwp:0012E3B0
<00882> 0038085C R WM_WINDOWPOSCHANGING
<00883> 0038085C S WM_CHILDACTIVATE
<00884> 0038085C R WM_CHILDACTIVATE
<00885> 0038085C S WM_WINDOWPOSCHANGED lpwp:0012E3B0
<00886> 0038085C S WM_MOVE xPos:14 yPos:103
<00887> 0038085C R WM_MOVE
<00888> 0038085C R WM_WINDOWPOSCHANGED
<00889> 0038085C S WM_PAINT hdc:00000000
<00890> 0038085C R WM_PAINT
<00891> 0038085C S WM_NCPAINT hrgn:84041466
<00892> 0038085C R WM_NCPAINT
<00893> 0038085C S WM_ERASEBKGND hdc:EE01123B
<00894> 0038085C R WM_ERASEBKGND fErased:False
As you can see, the window only start getting these messages after its position is less than 104 units. Does anybody know why this might be happening?
I should also point out that I am repositioning / resizing the window, and the messages only fail when the size is being reduced, there is no problem when being expanded. I have tried the repositing with both SetWindowPos() and MoveWindow() both giving the same results.
-- modified at 16:47 Wednesday 1st November, 2006
|
|
|
|
|
WM_PAINT is a low priority message. It will only be sent to a window when there are absolutely no other messages in the message queue. I do not know if this is what you are facing here as the 104 units thing is confusing. Without seeing the actual behaviour and code I can not tell you any more with the information presented.
|
|
|
|
|
Check that your main window's class styles include CS_HREDRAW|CS_VREDRAW. When you say you get no paint messages when making the window smaller, that's the normal behavior without those class styles - no portion of the client area is being revealed, so no painting is necessary.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
