Ok I need a programmer! I need to know if there is a way to make a string longer than 255 characters. I have a string that is 257 and it keeps dropping off the last two character. HELP ME
thanks in advance
stefee
I am using a string and putting sql statment inside.
example:
CString hold;
hold = "SELECT and some stuff";
hold += "FROM and some stuff";
hold += "WHERE and some stuff;";
return (hold);
but the string is missing the last two characters in the string, so I counted them and there are 257 characters needed in this string. Therefore, I figured it was b/c a string allows 255 characters. This sql code in the 'Database Project' of visual studio will work (minus the c++ parts of the code) and return the values needed, yet in the vc++ 'MFC AppWizard (exe)' it wont run.
While I agree with you that the documented max length of CString objects is a couple million. I too am experiencing similar troubles.
I'm testing the length by looking at the my CString object in the VC++ debugger. Interestingly enough I'm also using my CString object for a SQL statement. I take out a couple characters and the call works. Add to many and the last tick in a comparison gets cut off.
i.e.
WHERE TextField = 'stuff'
The second tick is getting cut off.
Thanks in advanced.
> I'm testing the length by looking at the my CString object in the VC++ debugger.
Yeah, the debugger only displays the first 255 characters! If you want to see what is in your CString you need to do something else with it, like put it in a multi-line edit box or write it to a log file or something.
We see people post messages in the ASP forum all the time that think their database problems are ASP related issues, and it turns out that they don't have a working SQL statement.
Here is a very simple test to work with databases.
*Throw a multi-line edit box into a dialog.
*In your code that builds the CString SQL statment use the completed CString contents to place the SQL statment text into the edit box on your dialog, i.e.:
CString sql;
sql = ....;
SetDlgItemText(IDC_EDSQL, sql);
*Now build and start the application.
*Run your application so that the sql statement appears in the dialog edit box.
*Copy the text to the Windows clipboard.
*Go to your database IDE (SQL Server Analyzer or Access or whatever)
*Paste the SQL statment from the Windows clipboard into your IDE's query window.
*Run the query in the IDE to 'PROVE' that it works. If there are problems your IDE should help identify them.
Ok,
I see your approach. I don't have access to VC++ currently, the compiler is at work. In the mean time please explain why the shorter sql call works while the longer one does not. If the VC++ editor just wasn't showing the full length of what was really in the CString object then I would think it should work in both cases.
When the SQL was longer I've coppied the SQL string to Access's SQL Query editor added the needed tick and submitted the query. This produced succesful results.
I'm sending the CString into my DLL's function that actually makes the SQL call. It is possible that this call is limiting me. I will check that on Monday. Otherwise I was at a loss on Friday as to why it was cutting me off. I've had plenty of experience with ASP/Cold Fusion. I'm now getting into C++. The knowledge barrier of C++ has been a difficult obstacle to overcome. I really appreciate the response to my statement.
Thanks,
Lange
> The knowledge barrier of C++ has been a difficult obstacle to overcome.
Well based on your description you are faced with much more than just C++. You are also taking on the burden of the Windows API, Windows SDK and a compiled language.
> I'm sending the CString into my DLL's function that actually makes the SQL call.
So, the string value is being passed through a chain of functions as a parameter. 'IF' data is being lost it can be occurring anywhere along the chain.
> explain why the shorter sql call works while the longer one does not
Without seeing and possibly running and modifying the code that may be impossible to determine.
> It is possible that this call is limiting me. I will check that on Monday.
'check that', Yes that is the attitude. Spending more than a few moments attempting to speculate what, where and when something is going wrong is a waste of time.
You need the ability to debug or log at every point within your code. This way you can 'absolutely' determine the cause by placing breakpoints and/or logging calls at the points in question. Thereby, examining the runtime state of your code and methodically arriving at the problem point.
"But, that's just my opinion... I could be wrong".
-pete
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.