cc:'d to poster >Ah, sorry I didn't make it terribly clear. I meant that I only ever get >a maximum of 255 chars returned.
O.K. - then that makes it seem a truncation problem and not a data definition problem. minor thing: in edit_exam_question.php there is " print '<a align="left">Select Correct Answer:<br>'; " What's the <a tag? I don't know that one :) You might want to add the 'readonly' attritbute to that textarea - lessens chance of unwanted post variables. You seem to be using that textarea only for displaying the retrieved question_text in: update_exam_question.php I see an update query ... there's an include call to dbconn.inc which I assume opens a connection ... and " SET question_text ="'.$question_text.'", " Where does this query get its data? From edit_exam_question which has a call to edit_exam_question.inc. which seems to be the code that queries for question_text. Later on there are three free_result calls so I assume in the .inc there are three queries? O.K. question_text gets printed in the textarea and then passed as a url parameter to update_exam_question. O.K. Either one of the unknown queries in edit_exam_question.inc is truncating the data or the url parameter is truncated, or dbconn.inc is the culprit. Three chances at answering the problem, not enough data. Except for the url parameter passing - but only id and question_id get passed so no chance on the parameter formatting Down to two chances. > Well, yes. The table in question is specified as such: > > CREATE TABLE [dbo].[tbl_exam_questions] ( > [question_id] [int] IDENTITY (1, 1) NOT NULL , > [question_text] [char] (400) NOT NULL , > [correct_answer] [int] NOT NULL > ) ON [PRIMARY] > data defintion seems to pass muster > I'm only using a very simple query (select * from tbl_exam_questions > where question_id=x;) and using the microsoft client tools such as query > analyser and ms sql enterprise manager, both return the full string. > O.K. the data is in the db and some tools can show you what you expect to see. That is good and bad news; good that the data is there in proper form eager to be retrieved; bad in that your code may be performing horrible vivisection experiments on the poor unsuspecting data. So - let's look at the .inc files that do the actual queries ... > I've attached the two related php files that deal with the process, I > can't see anything too horrible (other than my coding style) :-) ooops ... files attached only reiterate the problem and do not serve to further illuminate the path to happiness. more data::better answers Pan (side not to bob parker: huh? you have your attributes mixed up) -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
