By Aaron Young - 4/6/2008
Hi,I understand you use the UltraGrid and there is an Infragistics wrapper - although I haven't found it yet  . Does the wrapper support SF security and localisation or will I lose those? If so, which grid (if any) does support both as I don't believe you have a SF grid control? Thanks in advance, Aaron
|
By Trent L. Taylor - 4/6/2008
Does the wrapper support SF security and localisation or will I lose those? Yup. It supports both. There are some differences, but the security is implements at the BO field level, so it really doesn't matter what you are binding to. As for the localization, we support that as well. You can use our localization with any 3rd party control. If so, which grid (if any) does support both as I don't believe you have a SF grid control? You can use whichever grid that you want. If you implement the logic within the BO then you will not have any issues.
|
By Aaron Young - 4/6/2008
-- As for the localization, we support that as well. You can use our localization with any 3rd party control.To use localization with a third party control, for example a caption, I assume I simply code a call to your localization methods and manually set the caption with the string your code returns? The way you have described third party controls makes me think there is no real need for a wrapper. If so, what does your Infragistics wrapper add that I wouldn't get by using the Infragistics control itself? Also, where can I actually find the Infragistics wrapper? On a separate note, I see more references to DevExpress than Infragistics in the forums. Is DevExpress a better match for SF? Thanks for your help. I appreciate it. Aaron P.S. I hate being a newbie again
|
By Trent L. Taylor - 4/7/2008
To use localization with a third party control, for example a caption, I assume I simply code a call to your localization methods and manually set the caption with the string your code returns? You can add native support by implementing the ILocalizable interface...or just set the captions like you mentioned using the RetrieveTextValue method: MyControl.Text = MicroFour.StrataFrame.UI.Localization.RetrieveTextValue("MyKey") If so, what does your Infragistics wrapper add that I wouldn't get by using the Infragistics control itself? Also, where can I actually find the Infragistics wrapper? Native SF data binding without the need for using the Business Binding SOurce....and faster performance. Native .NET data-binding is slightly slower...so you would notice this on forms with a lot of controls. The Infragistics wrapper gets installed with everything else. It is called MicroFour StrataFrame Infragistics WRapper.dll. We will automatically create the toolbox items through the StrataFrame-Create Toolbox Tabs item in the menu. Just install Infragistics and you will be able to use the wrapper. On a separate note, I see more references to DevExpress than Infragistics in the forums. Is DevExpress a better match for SF? We actaully use Infragistics ourselves...and I am pretty confident that I see more people using Infragistics than DevExpress. The forum posts on DevExpress usually deal more with their grid...which behaves somewhat differently than all other grids that I have dealth with...though it is still a good grid and DevExpress has good controls. This choice is totally up to you
|
By Aaron Young - 4/7/2008
We already have the Infragistics controls so I am relieved to hear that.By the way, based on my posts on other support forums, I am not used to quick responses - you are too fast for me Thanks for the information and quick replies. Aaron
|
By Trent L. Taylor - 4/7/2008
By the way, based on my posts on other support forums, I am not used to quick responses - you are too fast for me LOL...glad we are exceeding expectations! 
|
By Aaron Young - 4/7/2008
Yes, you are exceeding expectations and my expectations were high after reading your entire website!For your information (and so you can have a laugh), I am here because I reported a bug for a competing system two months ago. I identified one of their routines that took 130 seconds to save a single record when equivalent C# .NET took 6-7 milliseconds (and yes and I do mean 130 seconds as opposed to 6-7 milliseconds - it is not a typo!). I had a dataset that contained around 13000 parent records and a similar no of child records. Admittedly a large dataset but only one record was modified before I did a save. Virtually the whole 130 seconds was spent by their custom code checking through the rows looking for modified records to save. The same code exists in .NET and I timed it on the same operation and it only took 6-7 milliseconds. After two months I am still waiting to hear if they believe this is acceptable performance and whether they are going to fix it. My only reply so far was that they had to check the child records too which accounted for the time - the point they missed was that the standard .NET code did exactly the same in a fraction of the time. Of course, this is the same company whose process for saving to a remote server was as follows (don't laugh): 1. On the client, you have a dataset containing 10000 rows. You modify a single row only and call their save routine. 2. The client sends the entire 10000 rows to the remote server in an uncompressed state. 3. The server scans through the 10000 rows, checking for modified rows only to find the one modified row which is then saved. The other 9999 rows are effectively disgarded. 4. To cap it all, the server then returns the entire 10000 rows back to the client (again uncompressed) and this replaces the 10000 row dataset that was originally sent to the remote server from the client in the first place. An interesting way of stressing the weakest link. To be fair, they fixed that in their latest release. Unfortunately, that is when the 130 second bug was introduced. Anyway, to be honest, don't care anymore. Performance and design like that I can do without Aaron
|
By Trent L. Taylor - 4/7/2008
Yeah, I understand how it goes in that arena. We didn't just wake up and decide to be a framework company one day. We actually purchased a number of our competitors and tried to use them for our medical software...and we ran into a number of scenarios like this and finally the one that broke the camel's back was when we saved, the and we were told it saved, but the records didn't really get saved. So we then decided that we would have to write our own framework...it took 2 fulls years and a serious commitment, but it has totally been worth it. That is the beauty of StrataFrame is that we use it ourselves for our medical software. And we too deal with very large databases and record sets dealing in the hundreds of thousands and in some cases millions of records. So we understand the importance of speed, reliability, and scalability!
|
By Aaron Young - 4/7/2008
It is a plus that you have your own application - particularly an application that manages large record sets. A number of "odd" barriers that I have previously hit appear to be covered by SF so I guess you have been there before I notice in the help file that 1 million is often referred to as the potential limit for the no of rows in a business object. While I would never intend to fill a BO with anywhere near this no of rows, is this the actual physical limit? Our largest customer database is around 125 million records so I just want to see if a customer should ever wisely or unwisely ask for an add-on with a BO with a huge no of rows that we have the option of delivering it. Just interested Aaron
|
By Trent L. Taylor - 4/7/2008
You would more than likely never make it to a million. This is by design of a disconnected data set. There is never any reason to ever have that many records on the client side. When you deal with this many records, you would be creating some type of calculation or update or potentially crunching massive amounts of data. When this is done, you would create a sproc or something along those lines that is called from the client and then processed on the server. The limitation is a moving line since it would come down to memory, etc.
|
By Greg McGuffey - 4/7/2008
I missed that there was any size limit on the number of records that a BO could handle (independent of hardware/network resources). I'll be interested to see if there is a limit.
Of course, network and hardware would likely be a limiting factor even if the BO can handle an unlimited number of records. 125 million records would require some serious memory and/or network connectivity (if you try to bring them all into the BO on a client machine....125 million records on an appropriately sized "modern" db server is very doable/done all the time). And then there is the issue of what in the world world would a user do with 125 million records available on their machine? If they browse a records every second, it would take something like 4 years to go through them (assuming no sleeping, eating, biology breaks at all).
If all 125 million records were all needed to perform some business logic, then I'd try to use SQL first. Or I'd try a server solution that sat very near the db (which might use a SF BO...if there aren't any limits). I know the SF guys use CLR sprocs to do heavy lifting like this, with great results (SQL 2005+).
Just some thoughts. I was intrigued by the post and thought I'd share them.
|
By Trent L. Taylor - 4/7/2008
Yeah, everything that Greg said is very true. I think that it pretty much re-emphasizes what I was saying but from just another perspective
|
By Aaron Young - 4/7/2008
I would agree that I would never intend to have anywhere near a million records let alone 125 million in a BO. I was simply interested to find out if 1 million was the physical limit as indicated in the help file. My reasoning is if SF can handle a BO with a million records then it will handle one with 10,000+.As I mentioned in an earlier post, I have had problems with another system that simply can't handle a large no of rows. True, even 10,000 records can be considered large but it should be possible to handle it. Thanks guys.
|
By Aaron Young - 4/7/2008
I can see why I couldn't find the Infragistics wrapper - it is looking for 7.3 and I have 8.1 installed.Nevermind, at least I know where to look.
|
By Trent L. Taylor - 4/7/2008
You can get that version here: http://forum.strataframe.net/Topic15184-22-1.aspx
|
By Trent L. Taylor - 4/7/2008
As I mentioned in an earlier post, I have had problems with another system that simply can't handle a large no of rows. True, even 10,000 records can be considered large but it should be possible to handle it. Yeah, you should be good here. We don't attempt to update all records, only records that have changed. So this part won't be an issue.
|
By Aaron Young - 4/7/2008
The link appears to be for DevExpress. I tried it anyway just in case but the Infragistics wrapper is still looking for 7.3Thanks
|
By Ivan George Borges - 4/7/2008
Hi Aaron.Try to follow these steps, and open the "MicroFour StrataFrame Infragistics Wrapper" solution instead of the "MicroFour StrataFrame Inherited UI": http://forum.strataframe.net/FindPost14742.aspx
|
By Trent L. Taylor - 4/7/2008
LOL...I thought about this on the drive home  When you purchase the framework, Ivan's solution will work as you have the source code and can hange the references. I have not yet taken the time to download 8.1 of Infragistics...so I will see if I can get that done sometime this week. Sorry.
|
By Aaron Young - 4/8/2008
Don't worry as we may have ordered by then. I can still test with the UltraGrid directly and the BusinessBindingSource. See, I am already posting like I know what I am talking about Thanks.
|
By Ivan George Borges - 4/8/2008
Oh, sorry Aaron, I thought you had the source code already. By the way, are you thinking of attending the classes in July?
|
By Aaron Young - 4/8/2008
No problem Ivan.I doubt I will be at the training in July. If we go for SF I will be expected to have progressed far by then. Also, distance is not on my side and it is hard to get a day off work let alone a week.
|
By Trent L. Taylor - 4/8/2008
Don't worry as we may have ordered by then. I can still test with the UltraGrid directly and the BusinessBindingSource. See, I am already posting like I know what I am talking about You are coming up to speed quickly! And we would obviously love to welcome you to the SF community!
|
By Greg McGuffey - 4/8/2008
Aaron Young (04/08/2008)
I doubt I will be at the training in July. If we go for SF I will be expected to have progressed far by then. Also, distance is not on my side and it is hard to get a day off work let alone a week.
Aaron, just so you know, this won't be your normal training class. First, the trainers (Trent and Ben) are first class .NET application developers. Not only do they develop SF framework, but they also develop a medical app (to help doctors manage their business). The second item of importance, is that they are very generous in sharing their knowledge (which is reflected here on the forum as well). So, the training class is great to get a developer up to speed on the SF framework, and it also is a great forum to develop .NET application development skills, at just about any level.
I took the class last May. I had been working with the framework for about 6 months (and developing with .NET for about 6 months), so I wasn't a noob, but certainly no where near fully competent with either. The class not only helped me get more competent, but also really helped with just general application issues. I can't recommend it enough. It is the only training class I've been too that I would even consider taking again...and I consider taking it as often as I can. (I think Ivan goes every time...but then he has a pretty savvy boss  )
I completely understand the issues of distance and time, which is why I not planning on being their in July (at this point). But I thought you'd like to know this isn't your normal training class and well worth the cost, time and effort.
|
By Ivan George Borges - 4/8/2008
(I think Ivan goes every time...but then he has a pretty savvy boss ) Oh, I know almost everything he has done during his life... so I just kind of blackmail him... 
|
By Greg McGuffey - 4/8/2008
ROFL
|