Skip to main content

Open ideas have been reviewed by our Product Management and are open for commenting and voting.

Filter by idea status

Filter by product area

4586 Ideas

df_cos
Contributor
df_cosContributor

Capture output to the "Messages" tab in SQL Server when a query runs using SQLExecutor in FMEOpen

This doesn’t currently seem possible so thought I would raise it as an idea to see if it is able to be implemented.In a nutshell, it is requesting a way to capture the same output you see in the “Messages” tab of SQL Server Management Studio, when firing off a SQL Stored Procedure using the SQLExecutor function in FME.Using an example to help explain this:There is a SQL stored procedure which, when run in SQL Server Management Studio, outputs a lot of PRINT statements to the “Messages” tab (highlighted below), which are really useful for troubleshooting the procedure if there are any issues encountered when running.  And also useful for seeing exactly what has run.  When this stored procedure is run using SQLExecutor in FME, although I have logging (including at debug level) in FME, it doesn’t capture these PRINT outputs, or any of the SQL queries that run for that matter.  An example of the output I am referring to is below (from SQL Server Management Studio).It would be really useful to capture this information in a log file/transaction log, so there can be a check each morning to see if any errors have occurred in the SQL stored procedure that has run overnight.  In some cases where the workspace completes successfully, but the SQL stored procedure does not, the log would show as completing successfuly but there wouldn’t be any indication in the FME log that there was an issue with the SQL stored procedure, i.e., it seems that everything has completed successfully when it actually hasn’t.The ability to capture this output from SQL Server would be very useful. 

bwn
Evangelist
bwnEvangelist

InlineQuerier: Support Spatialite DB FormatOpen

Suggest new InlineQuerier Parameter “Use Spatialite Extension?”No secret that I have been a SQLite/Spatialite fan, albeit very much from my SQL background 😉Still today though, there are certain operations that these SQL approaches are simpler and faster than FME Transformers.  What has been missing though is the huge library of Spatial SQL functions that could be utilised by InlineQuerier, if it had a Parameter to load the Spatialite extension.  This would significantly increase the workspace flexibility in being able to mix FME Transformers with in-workspace Spatial SQL parsing.Essentially this would provide FME with a ready-made spatial SQL black box with 100s of spatial functions to support its existing Transformers.https://www.gaia-gis.it/gaia-sins/spatialite-sql-5.1.0.htmlI believe that it is likely all the Parameter setting would need to toggle is an initial DB SELECT statement to be run immediately after DB open:SELECT load_extension('mod_spatialite'); or SELECT load_extension('libspatialite');https://www.gaia-gis.it/fossil/libspatialite/wiki?name=mod_spatialite...and ensure that mod_spatialite or libspatialite was resolvable to the Spatialite DLLs that are embedded inside FME already due to its Read/Write support for Spatialite (although updating them to the latest would be nice as well!  Alessandro: Spatialite author has spent a lot of time creating new SQL functions for Eg. Network tracing, Topology etc. not yet available to FME because of outdated DLLs)

itsmatt
Celebrity
itsmattCelebrity

Make it easier to output temp files e.g., with FeatureWriter/HTTPCallerOpen

**UPDATE** - This looks to be a duplicate idea of: https://community.safe.com/ideas/featurewriter%2Doption%2Dto%2Dwrite%2Dto%2Dtemporary%2Dfile%2Dwithout%2Dgiving%2Dan%2Dexplicit%2Dpath%2D32725The use of temp files in FME is not uncommon and the process for creating temp files right now in the middle of a workflow seems more complicated than it needs to be. The current workflow requires a user to put down a TempPathNameCreator and each feature which goes through this will create a new pathname, this is rarely desired. You need to use a FeatureMerger or something similar to get the correct path onto all of the feature which over complicates the process. Better would be an option to either put the same path on each feature, or add a GroupBy. Even better still would be an option directly in the FeatureWriter/HTTPCaller to just output to a temp location and doing away with need for the transformer in many workflows.An additional benefit of changing the way this works would also be in debugging. At present if you want to inspect the temp file in a workflow you either need to modify/disable parts of the workflow and/or change the path in the FeautreWriter/HTTPCaller. Furthermore, the TempPathnameCreator can also be a problem when working with partial runs, indeed, this probably won’t go away with adding the option to the FeatureWriter/HTTPCaller, however, it’s another issue which complicates the process.