Jump to content

DrSpaceMan

Members
  • Content Count

    4
  • Joined

  • Last visited

Community Reputation

0

About DrSpaceMan

  • Rank
    LAVA groupie

LabVIEW Information

  • Version
    LabVIEW 2012
  • Since
    2005
  1. Great advice. Thanks everybody. I was able to resolve this in a very very simple way: changed my provider in my datalink. I was using the more generic OLE DB provider but switching to the more native SQL server provider resolved it. This goes hand in hand with what candidus was saying. Below is an illustration of the difference between the 2 methods of connection:
  2. I've discovered a bit more and it seems to deal with the DECLARE @<variable> statement. For example: DECLARE @FOO varchar(100) = '123456' select BaseID, LotID, SubID, SplitID, InstanceID from MyTable where DrawingNumber LIKE @FOO and (LotID = 'EWR' or LotID = 'RWK') and Status = 'R' That does not work in LabVIEW or TestStand but it does work in other environments. Rewriting, the following works in LabVIEW select BaseID, LotID, SubID, SplitID, InstanceID from MyTable where DrawingNumber LIKE '%s' and (LotID = 'EWR' or LotID = 'RWK') and Status = 'R' an
  3. Thanks for the reply ShaunR. I had done that but it doesn't change the functionality, nor lead me anywhere. The more I use NI tools, I think it's not the string "" codes affecting it. If you take LabVIEW out of the equation and use TestStand's Database viewer tool or more simply calling Database steps (Open DB, Open SQL Statement, Data Operation, etc.), records are not returned. This leads me to believe it's something in the implementation of the NI SQL interface.
  4. Hi, I am connecting to an SQL server running 10.5. Using LabVIEW Database Connectivity toolkit and/or TestStand's Database Viewer I can successfully open a connection and run a simple query which returns the proper records. A more advanced query and no records are returned and the properties show that the state is closed. Copy and pasting this query into Microsoft SQL Server Management Studio successfully fetches the correct records. Also running this same query in python using pyodbc returns the correct record. The VI is straight forward. I attached the snippet. My first thought i
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.