Identify TimeSeries objects?
Posted in 2017
User asked how to identify TimeSeries system objects in Informix to separate them from user tables/functions in SQL editors. No built-in system table flag exists. Solutions offered: most TimeSeries objects are named with ts* prefix; examine $INFORMIXDIR/extend/TimeSeries* registration code; or compare dbschema output before/after creating a TimeSeries column.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Topics: Stored Procedures & SPL, Platform-Specific Issues
IDS 12.10.FC8W1WE on Windows Server 2012r2 Hi, We've recently started using timeseries. Once timeseries has been initialised for the database hundreds of new system objects are created (tables, functions, etc). Is there any way to easily identify these objects so that we can separate them out for display purposes, in sql editors like DbVisualizer for instance? At the moment they appear no different from our own tables/procedures/functions and all get munged together making it harder to find stuff that matters to us at a glance. I perused some of the system catalogue tables but couldn't see anything that identifies them as belonging to the timeseries additions, hopefully this info is stored somewhere however. Regards, Bryce Stenberg IT Department Harness Racing New Zealand Inc.
Lots of the tables are ts*, most of functions and api are similar but if you look in the $INFORMIXDIR/extend/TimeSeries* all the registration code is there. Cheers Paul > IDS 12.10.FC8W1WE on Windows Server 2012r2 > > Hi, > > We've recently started using timeseries. > Once timeseries has been initialised for the database hundreds of new > system > objects are created (tables, functions, etc). > > Is there any way to easily identify these objects so that we can separate > them > out for display purposes, in sql editors like DbVisualizer for instance? > > At the moment they appear no different from our own > tables/procedures/functions and all get munged together making it harder > to > find stuff that matters to us at a glance. I perused some of the system > catalogue tables but couldn't see anything that identifies them as > belonging > to the timeseries additions, hopefully this info is stored somewhere > however. > > Regards, > Bryce Stenberg > IT Department > Harness Racing New Zealand Inc. > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > -- Paul Watson Tel: +1 913-674-0360 Mob: +1 913-387-7529 Web: www.oninit.com Oninit® is a registered trademark of Oninit LLC Failure is not as frightening as regret. If you want to improve, be content to be thought foolish and stupid. What this country needs are more unemployed politicians
The "built in" TimeSeries functions, types, views, etc are stored along with
everything else - as far as I know they are not flagged as special in any
system tables. Only thing to do is to exclude them specifically by name.
They also appear in dbschema output for the database and dbexport, which can
be a pain when you don't want them...although the "-no-data-tables" and
"-no-data-tables-accessmethods" can help with dbexport.
Mike
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of BRYCE
STENBERG
Sent: Tuesday, March 28, 2017 7:53 PM
To: ids@iiug.org
Subject: Identify TimeSeries objects? [38811]
IDS 12.10.FC8W1WE on Windows Server 2012r2
Hi,
We've recently started using timeseries.
Once timeseries has been initialised for the database hundreds of new system
objects are created (tables, functions, etc).
Is there any way to easily identify these objects so that we can separate
them out for display purposes, in sql editors like DbVisualizer for
instance?
At the moment they appear no different from our own
tables/procedures/functions and all get munged together making it harder to
find stuff that matters to us at a glance. I perused some of the system
catalogue tables but couldn't see anything that identifies them as belonging
to the timeseries additions, hopefully this info is stored somewhere
however.
Regards,
Bryce Stenberg
IT Department
Harness Racing New Zealand Inc.
****************************************************************************
***
Forum Note: Use "Reply" to post a response in the discussion forum.
Simple suggestion to determine the answer for yourself:
Create a new empty database. Take a dbschema -ss output from that database
and save it to a file. This contains all base objects that are part of any
database. Now create a single table with a timeseries column. Run dbschema
-ss again to a new file. Diff the files. Now you know what belongs to
timeseries is everything in the diff output except the one table you
created.
Art
Art S. Kagel, President and Principal Consultant
ASK Database Management
www.askdbmgt.com
Blog: http://informix-myview.blogspot.com/
Disclaimer: Please keep in mind that my own opinions are my own opinions
and do not reflect on the IIUG, nor any other organization with which I am
associated either explicitly, implicitly, or by inference. Neither do
those opinions reflect those of other individuals affiliated with any
entity with which I am affiliated nor those of the entities themselves.
On Tue, Mar 28, 2017 at 9:52 PM, BRYCE STENBERG <bryce@hrnz.co.nz> wrote:
> IDS 12.10.FC8W1WE on Windows Server 2012r2
>
> Hi,
>
> We've recently started using timeseries.
> Once timeseries has been initialised for the database hundreds of new
> system
> objects are created (tables, functions, etc).
>
> Is there any way to easily identify these objects so that we can separate
> them
> out for display purposes, in sql editors like DbVisualizer for instance?
>
> At the moment they appear no different from our own
> tables/procedures/functions and all get munged together making it harder to
> find stuff that matters to us at a glance. I perused some of the system
> catalogue tables but couldn't see anything that identifies them as
> belonging
> to the timeseries additions, hopefully this info is stored somewhere
> however.
>
> Regards,
> Bryce Stenberg
> IT Department
> Harness Racing New Zealand Inc.
>
>
> ************************************************************
> *******************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--94eb2c0d738ebb44bf054bd590bc
Thanks Paul, Mike and Art - I'm disappointed there is not an easy way to see this is all system stuff, however I'll take your suggestions and generate my own list and see if the makers of the sql editor will add a filter to the product based on this (they already filter system objects to their own categories but that was probably easier based on id values). Regards, Bryce Stenberg.
Yeah, I agree. Trying to get myschema to filter out the timeseries stuff gave me a headache. The problem is that when TS was created back in the mid-'90s there was no intention to productise it, so the design wasn't done in an orderly manner with things like schemas in mind. It was originally done as a one-off for a bank in NY and kind of hung around unloved until smart meters came into being and the need was there for it again. Art Art S. Kagel, President and Principal Consultant ASK Database Management www.askdbmgt.com Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Wed, Mar 29, 2017 at 4:36 PM, BRYCE STENBERG <bryce@hrnz.co.nz> wrote: > Thanks Paul, Mike and Art - I'm disappointed there is not an easy way to > see > this is all system stuff, however I'll take your suggestions and generate > my > own list and see if the makers of the sql editor will add a filter to the > product based on this (they already filter system objects to their own > categories but that was probably easier based on id values). > > Regards, Bryce Stenberg. > > > ************************************************************ > ******************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --f403045d5a6c24947a054be55518