in reply to Re: OT?>> DBD::ODBC::st execute failed: NULL textptr passed to UpdateText function-- why??
in thread OT?>> DBD::ODBC::st execute failed: NULL textptr passed to UpdateText function-- why??

Thanks for the reply.

Yes, I think I'm certain that the row being updated does exist- I am pretty sure that is not the problem. Also, updates on non-text fields never fail, and the users are usually able to "hit the back button and try again" I am told. (this is why I thought a retry in a loop might help)

However, you are right - I do not yet know if it is dependent on the input data which is bound to the parameters. I should include the bound parameter values in my error page. I think this will be my next step.

It is difficult because I'm forced to debug this by providing patches - I don't have access to the server that runs my application. Worse yet, the people who run the patches are in a timezone 12 hours different than mine! So it's a slow process.

Thanks-

Matt
  • Comment on Re^2: OT?>> DBD::ODBC::st execute failed: NULL textptr passed to UpdateText function-- why??

Replies are listed 'Best First'.
Re^3: OT?>> DBD::ODBC::st execute failed: NULL textptr passed to UpdateText function-- why??
by terce (Friar) on Jun 06, 2005 at 15:49 UTC
    I've just had a chance to do some testing on this.

    It looks like the problem is your code attempts to use the UPDATETEXT command on a text field which is currently set to NULL. Certainly, attempting to do this will produce the error message you report.

    You can test this using the attached script, which creates a table (text_text) with an id column, a varchar field and a text field, inserts two rows with the text field set to null, updates the first using a regular update statement then amends it with UPDATETEXT, then updates the second (null) text field using UPDATETEXT.
    CREATE TABLE [test_text] ( [id] [int] IDENTITY (1, 1) NOT NULL , [vc] [varchar] (50) COLLATE Latin1_General_CI_AS NULL , [txt] [text] COLLATE Latin1_General_CI_AS NULL ) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY] GO insert test_text (vc) select 'hello, number 1' go insert test_text (vc) select 'hello, number 2' go update test_text set txt = '12325rfegsfdgervsdfgvsdfgvfdsgv' where id = 1 go DECLARE @ptrval binary(16) SELECT @ptrval = TEXTPTR(tt.txt) FROM test_text tt WHERE tt.id = 1 UPDATETEXT test_text.txt @ptrval 16 1 'b' GO DECLARE @ptrval binary(16) SELECT @ptrval = TEXTPTR(tt.txt) FROM test_text tt WHERE tt.id = 2 UPDATETEXT test_text.txt @ptrval 16 1 'b' GO
    Perhaps ODBC statements use UPDATETEXT rather than a conventional update statement. I realise it's late in the day to be suggesting this, but do you have to use ODBC rather than OLEDB?

    UPDATE: A further test reveals that executing the SQL directly using Win32::ODBC does not show a similar error. I don't have time to run the test using DBD::ODBC, but it's possible that that's where the problem lies.
      It would seem that *something* is calling UpdateText-although I am not doing it directly. I am only using ANSI sql.

      It is curious why i cannot get this test/example (below) to fail:

      If I have a table with (mrID, mrDESCRIPTION) which is an (int, text)--

      I can have $data be an empty string, or hava a value.

      eval { $dbh->do("DELETE FROM MASTER1 WHERE mrID=999"); $dbh->do("INSERT INTO MASTER1 (mrID) VALUES (999)"); $sql = "UPDATE MASTER1 SET mrDESCRIPTION=? WHERE mrID=999"; $sth = $dbh->prepare($sql); $sth->bind_param(1, $data, DBI::SQL_LONGVARCHAR); $sth->execute(); $dbh->commit(); };
      This is a simplified version of what IS apparently failing for the user... hmm. And thanks for the example!

      Matt