Unable To Delete Data Row - Unassigned Machine

We have two data rows that we can’t delete because it says it’s running at an unassigned machine, I’ve reset all of the machines we used and I’m still unable to clear this. I’m thinking maybe some of my users logged into a different windows account and loaded the app and didn’t close it properly… that’s very difficult to track down, is there a simpler way to override this so these data rows can be removed?

hello @ashchav20, there unfortunately isn’t a way to delete a Table Record if it’s still loaded on a Device (even if it’s not assigned to a Station).

to delete the Record, you can temporarily assign the Device to a Station, change the App that it’s running (so the Record is no longer loaded), and then you can go ahead and Delete the Record. could you let us know if this works for you?? thanks!!

Thanks @gio, unfortunately I’m not sure what device it is :sweat:

I have the same issue. no sure what device it is.

hello @ashchav20 and @mcc6025, are you trying to empty the entire Tables?? if so, the DELETE /tables/{tableId}/records endpoint has a parameter called allowRecordsInUse that allows you to Delete all Records even if they’re being used.

more information on how to use this API endpoint can be seen here: [Tip of the Week] Delete all Table Records using a Bot. but as mentioned in the post, please use with caution as all Table Records will be deleted.

hey @gio, I am not wanting to clear all table records, but since you are able to set a parameter to delete all records in use, would it be possible to set that as the only parameter to delete records from a table?

If so, I could have my team close out of the current apps they’re in, then execute that parameter to delete data rows from records in use.

The issue is right now my main data table receiving input from all apps is showing there’s two data rows open under “unassigned machine” so we have no way of tracing it back to where it was created.

@ashchav20, one thing you could do is set up a new dummy Station, and flip through the display devices that are not assigned (the fact you’re seeing “unassigned machine” means that it’s not at a Station currently). if you go through them all it will clear any persistent Table Records that were loaded.

at that point, you’ll be able to Delete the Records.

would this work as a solution?? let us know!!

@ashchav20 I think a similar, alternative approach here would be to enable functionality around the allowRecordsInUse API query parameter for the single record delete, as well as the delete endpoint to truncate the entire table. That flag allows us to override the rows that are currently loaded at a device and delete rows regardless of status.

This would allow you to run a simple API request to manually clean up these stuck rows, which as @gio mentioned, are being used by a display device that is no longer assigned to a station.

Does this sound helpful? I’ve created the request internally already, but would be good to hear your thoughts!

1 Like

I might be off-topic with this thought but I only recently discovered that, when you have a display device that is not assigned to a station, that device will inherently use the development version of the app. For me, this was a problem because display devices were getting bumped off assigned stations and then unknowingly writing to the development database environments. For reasons not worth getting into here, I can’t yet control this behavior and had to disable the non-production data sources in the related connector.

This almost sounds like the opposite problem. Machines that probably should not be participating in the production environment are impacting production because there is no separation of environments for Tulip tables (at least not last time I checked, sorry if that has changed).

Things I wish Tulip had related to this:

  1. Some sort of abstraction of Tulip tables for dev purposes. I don’t have this all thought out but, if relevant tables could be partially loaded into a development or test session and any changes be dropped at the end of that session, with no appearance of the work in production, that would be cool. There is probably a better way to do this, I’m just spitballing.
  2. Some way to hunt down unassigned display devices from within the admin site.
  3. An easy way in the Tulip player to see: Display Device name, Assigned station, running application version.