Logic Apps - Connector - Error When Using SQL 'Get Row (V2)' On Custom Value Table Which Cannot See Same Table As 'Get Rows (V2)'

[influential-eliot]

Describe the Bug

When attempting to use an On Prem SQL DB I am seeing strange behaviour that has not occurred previously with the SQL 'Get Row (V2)' action.

1. Rejects Any Integer, GUID, Unique Ref

   I cannot retrieve any items from the selected table.

   Each attempt is met with a '400' error (not found) from the request made.

   With regard to the selected table it must be entered as a 'Custom value' in the I cannot retrieve any items from the selected table, as per the next item. Imagery is available for this in the Errors section here.

2. Does not Show Same Table As 'Get Rows (V2)' Action

   Simply put, when I use the 'Get Rows (V2)' action it will list the table, but when I use the 'Get Row (V2)' action it does not.

Plan Type

Consumption

Screenshots or Videos

See error response details.

Steps to Reproduce the Bug or Issue

1. Ensure On-Prem SQL DB & Table; ... by making sure that you are connecting to a *non*-Azure SQL database that is connected to via a gateway, with the following columns named however you wish:
   • Unique, Numerical, Primary Key
   • Unique, String, Reference Number
2. Make Consumption LA; ... normally via adding a new resource to the resource group
   1. Add Trigger & Response; using the '_Request_' trigger/action (_HTTP_)
   2. Add SQL Server Actions; for '_Get Rows (V2)_' and 'Get Row (V2)' after that
3. Test Consumption LA; ... by triggering it and changing the '_Row ID_' to the different references

Workflow JSON

None, yet, I may build obfuscated code, if required.

Additional context

Database Details

I spoke to the database owner who checked the permissions on the DB, and the user involved has full access to this table (only), tap here for images.

Other Attempts

I wanted to test whether the GUI was altering the code incorrectly and sending a text value instead of a numerical one, so I also attempted ^{REF:Errors/Primary Key/Relevant Details} to force that by removing the encoding enforced via editing the 'code' view.

This changed nothing, but, equally, the system may still be sending the information as a string instead of a numerical value ... I cannot control the backend, however, instinct says it is not this.

Errors

In the below expandable content are the instances of the error from 'forcing' the table name with difference references that should beget data.

• Primary Key

  I figured this should be the one which works, here.

  Relevant Details

  • 1234 = Example - When searching for the primary key, let us assume that the '1234' below is the primary key.
  • Setup - Said primary key has '(decimal(10,0),not null)' as its setup.
  • Other Attempts - I tried for the _first_ row item with '1' which also failed
  • Forced Integer - I modified the code in code view by removing the '`@{encodeURIComponent(encodeURIComponent('1')) wrapping}`' which also failed
  • Error - See below JSON code section

  Response Body

  {
    "status": 400,
    "message": "The specified item '1234' is not found.\r\n     inner exception: The specified item '1234' is not found.\r\nclientRequestId: OBFUSCATED_CLIENTREQUESTID",
    "error": {t
      "message": "The specified item '1234' is not found.\r\n     inner exception: The specified item '1234' is not found."
    },
    "source": "sql-uks.azconn-uks-002.p.azurewebsites.net"
  }

  Input Image

  

• Microsoft GUID (Aka 'ItemInternalId' Key Name)

  Relevant Details

  • Changes Every Time - When I run the '_Get Rows (V2)_' previously this ID changes with every attempt and my gut is telling me that this should NOT be the case
  • Error - See below JSON code section

  Response Body

  {
    "status": 400,
    "message": "The specified item 'GUID-ID-CHARACTERS-WERE-HERE' is not found.\r\n     inner exception: The specified item 'GUID-ID-CHARACTERS-WERE-HERE' is not found.\r\nclientRequestId: OBFUSCATED_CLIENTREQUESTID",
    "error": {
      "message": "The specified item 'GUID-ID-CHARACTERS-WERE-HERE' is not found.\r\n     inner exception: The specified item 'GUID-ID-CHARACTERS-WERE-HERE' is not found."
    },
    "source": "sql-uks.azconn-uks-002.p.azurewebsites.net"
  }

  Input Image

  

• Unique Reference Number

  Relevant Details

  • 123456 = Example - When searching for the primary key, let us assume that the '123456' below is the primary key.
  • Setup - Said primary key has '(varchar(20),not null)' as its setup.
  • Error - See below JSON code section

  Response Body

  {
    "status": 400,
    "message": "The specified item '123456' is not found.\r\n     inner exception: The specified item '123456' is not found.\r\nclientRequestId: OBFUSCATED_CLIENTREQUESTID",
    "error": {
      "message": "The specified item '123456' is not found.\r\n     inner exception: The specified item '123456' is not found."
    },
    "source": "sql-uks.azconn-uks-002.p.azurewebsites.net"
  }

  Input Image

  

Browser Engine Check

I have tried this in both Gecko and Chromium browser engines, but I did not believe that this was a reason for the issue.

---

Pertinent Updates

Below are any updates that may be relevant to the issue.

1 - SQL Table Has No Primary Key

^{2026-02-26T15:50:00.0000000}

I was uncomfortable with the setup, here, because I didn't think that the connector / system would really be the issue, here, as it's always worked for me before. So, in looking for workarounds, we focused on setting up a Stored Procedure, in doing so that invoked the SQL experts at my company.

Said experts managed to get a perspective that I didn't have (still relevant to issue - see below expand) and that is that the client's DB table does not have a Primary Key defined.

Getting this will likely resolve the issue that we have.

Why This All May Still Be Relevant?

So, just a quick side-note, I took a look at the call that the GUI makes to Azure to build the UI.

Said 'dynamicinvoke' requests that the Azure GUI client ACTUALLY makes identified that this column WAS the primary key.

OK, maybe not explicitly ... heh ... I cannot be one-hundred percent on that, based on the below, and I may be guilty of misreading the 'required' column AS the primary key ... but ... still ... it's something.