1

I'm using npgsql as a nuget package in visual studio 2017 with visual basic. Various commands do work very well but an ExecuteScalar allways returns 'nothing' although it should give a result.

The command looks like this:

   Dim ser As Integer
   Dim find = New NpgsqlCommand("SELECT serial from dbo.foreigncode WHERE code = '@code';", conn)
   Dim fcode = New NpgsqlParameter("code", NpgsqlTypes.NpgsqlDbType.Varchar)

   find.Parameters.Add(fcode)
   find.Prepare()

   fcode.Value = "XYZ"

   ser = find.ExecuteScalar()     ==>  nothing

When the command string is copied as a value during debugging and pasted into the query tool of PGADMIN it delivers the correct result. The row is definitely there.

Different Commands executed with ExecuteNonQuery() work well, including ones performing UPDATE statements on the row in question.

When I look into the properties of the parameter fcode immediately before the ExecuteScalar it shows 'fcode.DataTypeName' caused an exception 'System.NotImplementedException'.

If I change my prepared statement to "SELECT @code" and set the value of the parameter to an arbitrary value just this value is returned. There is no access to the table taking place because the table name is not part of the SELECT in this case. If I remove the WHERE CLAUSE in the SELECT and just select one column, I would also expect that something has to be returned. But again it is nothing.

Yes there is a column named serial. It is of type bigint and can not contain NULL. A Query shows that there is no single row that contains NULL in any column.

Latest findings: I queried a different table where the search column and the result column happen to have the same datatype. It works, so syntax, passing of parameter, prepare etc. seems to work in principal. The System.NotImplementedException in the DataTypeName property of the parameter occurs as well but it works anyway. I rebuilt the index of the table in question. No change. Still: when I copy/paste the CommandText and execute it in PGAdmin it shows the correct result. Modifying the Command and using plain text there without parameter and without prepare still does yield nothing. The plain text CommandText was copy/pasted from PGAdmin where it was successfully executed before. Very strange.

Reverting search column and result column also gives nothing as a result.

Rainer
  • 21
  • 4
  • 2
    Are you sure you need the single quotes around @code in the select statement? – Honeyboy Wilson Feb 17 '20 at 19:47
  • `Dim fcode = New NpgsqlParameter("code"` <- that should probably be `"@code"`, and it is normal to specify the size of string parameters to match the declaration in the database. – Andrew Morton Feb 17 '20 at 19:54
  • Removing the single quotes did not change anything. Also taking them to the assignment of the value did not change anything. Varying between "@code" and "code" for the parameter name did not change anything. In all other commands (which work) its "@code" where it is used in the SQL and "code" in the declaration. I also added the size of the varchar according to the DB, but this again did not change anything. – Rainer Feb 17 '20 at 22:15
  • Maybe try producing a minimal sample, including the table being created and the rows being inserted into it - I can see my version of this running fine. Also, if `SELECT @code` works then `SELECT x FROM y WHERE z=@foo` should definitely work - from Npgsql's perspective both are identical. – Shay Rojansky Feb 18 '20 at 08:30
  • @Shay I just added my latest findings to the original post. I tried what you describe. – Rainer Feb 18 '20 at 08:43
  • The NotImplementedException in the DataTypeName property is expected, this is currently basically a write-only property; you should only be using it to set the PG data type you want to send (it should have been made properly write-only). This has nothing to do with your issue. – Shay Rojansky Feb 18 '20 at 08:55
  • From what you're writing, I'd really double-check that you're querying the right row from the right table (with the right parameter in the WHERE clause) - everything seems to be working for you when doing a different query... – Shay Rojansky Feb 18 '20 at 08:56
  • @Shay As written in my latest findings. I'm sure to perform the right query. When I copy/paste the CommandText to PGAdmin and execute the query there it gives the right result. – Rainer Feb 18 '20 at 10:58
  • Well I can't repro it... If you start from scratch, create an empty new database and table, and write a minimum program, can you reproduce the issue? – Shay Rojansky Feb 18 '20 at 12:33

2 Answers2

1

Please try these two alternatives and post back your results:

' Alternative 1: fetch the entire row, see what's returned
Dim dr  = find.ExecuteReader()
While (dr.Read())
  Console.Write("{0}\t{1} \n", dr[0], dr[1])
End While

' Alternative 2: Check if "ExecuteScalar()" returns something other than an int
Dim result = find.ExecuteScalar()

... and (I just noticed Honeyboy Wilson's response!) ...

Fix your syntax:

' Try this first: remove the single quotes around "@code"!
Dim find = New NpgsqlCommand("SELECT serial from dbo.foreigncode WHERE code = @code;", conn)

Update 1

Please try this:

 Dim find = New NpgsqlCommand("SELECT * from dbo.foreigncode;", conn)

Q: Does this return anything?

Dim dr  = find.ExecuteReader()
While (dr.Read())
  Console.Write("{0}\t{1} \n", dr[0], dr[1])
End While

Q: Does this?

Dim result = find.ExecuteScalar()

Q: Do you happen to have a column named "serial"? What is it's data type? Is it non-null for the row(s) with 'XYZ'?

Please update your original post with this information.


Update 2

You seem to be doing ":everything right":

  • You've confirmed that you can connect,
  • You've confirmed that non-query updates to the same table work (with npgsql),
  • You've confirmed that the SQL queries themselves are valid (by copying/pasting the same SQL into PGAdmin and getting valid results).

As Shay Rojansky said, "System.NotImplementedException in the DataTypeName property" is a known issue stepping through the debugger. It has nothing to do with your problem: https://github.com/npgsql/npgsql/issues/2520

SUGGESTIONS (I'm grasping at straws)::

  1. Double-check "permissions" on your database and your table.

  2. Consider installing a different version of npgsql.

  3. Be sure your code is detecting any/all error returns and exceptions (it sounds like you're probably already doing this, but it never hurts to ask)

... and ...

  1. Enable verbose logging, both client- and server-side:

... Finally ...

Q: Can you make ANY query, from ANY table, using ANY query method (ExecuteReader(), ExecuteScalar(), ... ANYTHING) from your npgsql/.Net client AT ALL?

FoggyDay
  • 11,962
  • 4
  • 34
  • 48
  • Alternative 1 yields nothing. Alternative 2 also yields nothing When I "simplify" the SQL Statement to just "SELECT @code" the correct value is returned. So I assume the naming and usage of the Parameter is correct. – Rainer Feb 17 '20 at 22:31
  • All three attempts of the Update have the same result ==> nothing – Rainer Feb 18 '20 at 10:50
  • You seem to be doing "everything right". Please see my updates. – FoggyDay Feb 18 '20 at 17:59
1

I finally found it. It's often the small things that can have a big impact. When the value was assigned to the parameter a substring index was incorect. Now it works perfectly. Thanks to everybody who spent his time on this.

Rainer
  • 21
  • 4
  • Glad you got it resolved ... but please clarify. Update your post with example code, if at all possible. Please explain how you found the problem; what troubleshooting steps you took. And please consider "upvoting" my response. – FoggyDay Feb 19 '20 at 05:17
  • @FoggyDay The error was in another area of the program and had nothing to do with the requests as such. So I did not make any changes to the statements that I posted. Just the single quotes were removed. Thanks again for the help. I tried to upvote your answer but my vote will not be counted because I'm to new to stackoverflow. – Rainer Feb 19 '20 at 19:40
  • Thank you. And thank you for posting back the resolution! – FoggyDay Feb 19 '20 at 19:41