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
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
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
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
(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