How are UDTs represented internally inside a tag provider/db?

I'm about to start working with some UDTs, and I want to get a grounding in how they're represented inside the database.

If you're talking about the DB on disk in the background, you don't need to know how they're stored to use/make UDTs.

If you haven't gone through Inductive University, I suggest going through ALL the videos there. If you want to learn about UDTs, here's the relevant videos:

I'm looking to get a sense of how they're stored in the background DB, since I will be running queries from external services into that DB and want to know how to understand those queries.

That DB is a SQLite DB and is going away in v8.3 if I understand correctly, so I wouldn't rely on it. That DB also doesn't store live values from OPC, etc so if you're wanting live data, you're better looking into the WebDev module to write an API, or using transaction manager to store live values in a database with the format of your choice.

You might also explain EXACTLY what you're trying to do so anyone reading this can help you find the proper solution for your end goal.

1 Like

Oh, I mean "If i'm using a postgres tag provider or similar, what tables are those UDTs going to be written to in that tag provider, etc"

Actually, I've realized I misunderstood -- those tag providers are just for historizing data, not for the actual tag schemata (which are just stored in the internal config db/in the jsonified format in 8.3)

To better understand the Historian table schema:

Though, there are some built in functions that make querying of tag history a breeze. My most-used:

If you need external access to query or interrogate tags, I second the recommendation to build an API (via WebDev module).

Otherwise, system functions are accessible from within Ignition, where you can write your own script to interrogate (& export) data.

Some useful functions:

There is also a Tag Report Tool which adds a GUI for quick generation of a tag query intended for use in scripting.

You probably shouldn't be querying the config.idb while ignition is running, but if you did, the tags are linked together using uuids and parent uuids. You'll have fun piecing everything together :slight_smile: (I don't have it open so can't go into specifics...)

3rd vote for writing functions in webdev to retrieve tag json via an api call though. Or depending what you want to do with it, you could also have ignition update a sql table with a list of every tag in the system of that will suffice. Or even chuck the whole tag json into a table field... Or into a file that your other app can read

Yeah, most of us don't call those tag providers. Those are history providers for tags. Tag providers are for live data.

1 Like