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

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.

You can use whichever grid that you want.  If you implement the logic within the BO then you will not have any issues.

-- 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  

You can add native support by implementing the ILocalizable interface...or just set the captions like you mentioned using the RetrieveTextValue method:

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.

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

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

LOL...glad we are exceeding expectations!

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

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!

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

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.