Common Dataset Errors

For those looking to help diagnose some dataset syncing issues or errors, this document is a compendium of a few we've seen and steps that can be taken to help fix.



This is by far our most common dataset error.  In our default datasets, we try to prevent this by limiting the amount of data pulled in, but in some instances, even that is not enough.  This is caused by large influxes of data ( often due to mass updating old tickets or an RMM creating lots of tickets).  Our support team will be glad to work with you on limiting the data pulled when this occurs on default datasets.  For custom datasets, they can take a look and give you pointers as well.



This is an error due to the need to use a function SQL Server to help expose some data. Currently, this only exists in a few ConnectWise On-Premise datasets.  To help rectify this, take a look at this document for help on adding the permissions.  Support can help guide you through it as well.



Older iterations of SQL Server (2008 and before) lack the concat() function which some default datasets use.  Reach out to our support team for help on removing that function from your datasets.  


Datefromparts error

This error shows itself as: 'datefromparts' is not a recognized built-in function name. What this means is that a function of SQL Server we're using to create a date is not available in your version of SQL Server. It started with SQL Server 2012, but no worries we can make an adaption on the back end. Reach out to our support team and let them know if you're having a datefromparts error here.


Invalid object error

This error means that a table used in a default dataset is not there.  In most instances, this means that you are on an earlier version and need to upgrade or in rare instances, the table is not a part of your setup.  For custom datasets, this usually means that the table you were using no longer exists.  To see if a fix is available, reach out to our support desk for more information.



This is an odd error where the database kills our query due to another process that has locked the table(s) our query is trying to read.  This is normally a rare occurrence for us since deadlocks normally affect processes writing to a table instead of just reading (SQL queries do lock tables, but release them quickly), but there still have been situations where we encounter these.  If you experience deadlocks, it's best to look into what is using the database first.  These other processes are what are causing BrightGauge's queries to be locked out.  For help, you should contact the vendor that set up your SQL database or consult a database administrator (DBA).  As a last-ditch effort, BrightGauge can help work around these errors, but again it's a last-ditch effort since the workaround can cause incorrect data to be read.  For more on this, you can read Microsoft SQL Server documentation here or reach out to our support team.


Was this article helpful?
0 out of 3 found this helpful