Hi,
I am curios to know if easychart is develop by you guys or do you use a a chart control like gigasoft or chartfx and program around it. If it is a third party control do you mind sharing who makes it.
Thanks
Julio D
All of our charting is based on the JFreeChart library, you can find more at jfree.org/jfreechart/
The easy chart in particular is of course highly customized and specialized for our purposes, but JFreeChart is the base charting library used.
Thinking of rolling your own charting app?
[quote=“Carl.Gould”]All of our charting is based on the JFreeChart library, you can find more at jfree.org/jfreechart/
The easy chart in particular is of course highly customized and specialized for our purposes, but JFreeChart is the base charting library used.
Thinking of rolling your own charting app?[/quote]
Carl,
Thanks for the quick ans. I have been using ChartFX and dotnetcharting controls in our ASP.NET applications. We are currently evaluating our systems looking to see that else is available. We are thinking of using FactorySQL instead of RSSQL but I think I’ll wait for the Stored Procedure feature instead of building the temp table … Today we log all the information to MS-SQL using RSSQL (our data objects are SP’s) and for presentation and trending we have the ASP.NET application.
Thanks
Sounds like a plan - FYI, we do plan on adding SP support to FactorySQL quite soon, so stay tuned!
Hey, I have a question. We’ve noticed that SQL Server users are really into their stored procedures, even when the SP does no special computation beyond what raw SQL could do. The same isn’t true with users of other database systems. Why is this? Do they say “Thou shalt use stored procedures for everything” in MS-SQL 101?
Just wondering,
[quote=“Carl.Gould”]Sounds like a plan - FYI, we do plan on adding SP support to FactorySQL quite soon, so stay tuned!
Hey, I have a question. We’ve noticed that SQL Server users are really into their stored procedures, even when the SP does no special computation beyond what raw SQL could do. The same isn’t true with users of other database systems. Why is this? Do they say “Thou shalt use stored procedures for everything” in MS-SQL 101?
Just wondering,[/quote]
I used store procedure because we do some data validation and conversion before we insert the data, in one transaction I may affect multiple tables, always have an output parameters that I send back to the PLC to indicate if the data was inserted and valid. Also if I need to send data back to the plc I pass my inputs parameters for my filter and the outputs are the data send back to the plc (we used for recipe downloads, product tracking and diversion, getting quality specs …).
See that is the way RSSQL supports does requirements by using SP’s. Also
SP’s are supposse to be faster since they are precompiles. Question on FactorySQL, can I write all my sql statements so if I used if then else converts, sets …
Thanks
Fair enough. There is a bit of a shift in design thought you need to undergo in order to configure comparable systems using FactorySQL.
For instance, you can do data conversion/maniuplation using an Action Item in your FactorySQL group, rather than if/then else, etc in Transact-SQL.
In FactorySQL, you’d send data back to the PLC with bi-directional groups or custom item modes in other groups. To use PLC data as filters you’d reference them in your where clause, use them as triggers, or reference them is SQL query action items.
It is true that SPs are precompiled. In practice, this is a marginal savings. You typically write some parts of the queries that run your groups, such as the WHERE clause.
Anyhow, I guess the moral of the story is that there isn’t a 1-to-1 design correlation with a RSSQL project and a FactorySQL project. The same ends can be achieved, but you use varied means to acheive them. RSSQL uses SPs to push most of the data processing into the databases. FactorySQL lets you configure your groups to do most of that data processing for you, to avoid having to write SPs. As mentioned before, we will soon have more support for SPs to encourage RSSQL converts.
Hope this clears some things up,
I just wanted to add in that we’re adding stored procedure support in 4.0 (due to release in october), not only to attract RSSQL converts, but also because they are, in fact, a very powerful DB feature.
I think what Carl was getting at is that we have a lot of customers who try to use stored procedures when it’s not necessary, and when the task can be accomplished naturally and with the same efficiency in FSQL. The example JDelgado gives is a valid use of SPs- preprocessing data, writing to multiple targets, etc. Most of this can probably still be done in FSQL, but if you’ve already got the procedures, why not use them? Also, usually stored procedures offer a LOT more ‘potential’ power than FSQL could, by letting you write them in full programming languages- for example, C# in ms-sql.
In FSQL 4 we hope to have 2 forms of support: a new Stored procedure group, and a stored procedure mode for action items. This will make stored procedures a 1st class citizen in terms of FSQL techniques/features.
Regards,