I am working on our first xojo web 2.0 project. I am using Graffiti Suite plugins and MBS Plugins.
I have created a Graffiti Suite Grid that displays about 6000 rows of data from my MSSQL Server Db.
Although my code finishes, my webpage is blank and when i open inspect I see multiple lines of
Failed to load resource: The network connection was lost. I have attached my code below.
Can anyone give me any suggestion on how to solve this?
Thank you in advance.
if ivshop <> Nil and ivShop.ersh_id>0 then
Var rs as RowSet = Session.db.selectSQL("SELECT EAD_ITEMS.*,VE_INV_RETAIL.* FROM VE_INV_RETAIL LEFT OUTER JOIN EAD_ITEMS ON EAD_ITEMS.ei_number = VE_INV_RETAIL.ei_number and ersh_id = "+ivshop.ersh_id.tostring)
Var lvRows() as Graffitigridrow
if rs <> nil then
Var ct as Integer = 1
Var i as new EAD_ITEMS
if rs.column("eai_id").Int64Value>0 then
Var inv as new VE_INV_RETAIL
Var dict as new Dictionary
dict.value("aa") = ct
dict.value("ei_code") = inv.ei_code
dict.value("ei_description") = inv.ei_description
dict.value("eirtl_omada") = inv.eirtl_Omada
dict.value("eai_price_sal") = i.eai_price_sal
dict.value("eai_price_out") = i.eai_price_out
dict.value("eai_price_del") = i.eai_price_sal
dict.value("eai_price_idiokat") = i.eai_price_sal
dict.value("eai_active") = i.eai_active
dict.value("eai_famous") = i.eai_famous
dict.value("eai_order") = i.eai_order
Var shItem as new ShopItem
shItem.ivItem = i
shItem.ivView = inv
Var row as new Graffitigridrow(dict)
row.tag = shitem
if ct mod 500 = 0 then
ct = ct + 1
if lvRows.count>0 then
If lblist is a GraffitiGrid, you should set the LockUpdate property to True in the first line, and set LockUpdate to False as the last line. This causes the Grid to send all of the data updates (new rows, deletions, insertions) as a single optimized packet. Loading massive amounts of data is vastly improved using this method.
lblist.LockUpdate = True
'// All the rest of your code to add or remove rows
lblist.LockUpdate = False
If you still have trouble, please open a support ticket and I’d be glad to take a look at an example project showing the issue.
Ah, missed the first time around that you’re using AddRows, which does this for you. I regularly test GraffitiGrid using 10,000 or more rows, so that shouldn’t be the issue.
It may be your UpdateBrowser calls, which GraffitiGrid doesn’t support anyway. Especially in the loop where you’re not making any actual changes.
UPDATE: OK, I think I see the problem. Sorry, it’s early and been a rough few days. You’re calling AddRows with the content of the array in 500 row increments. You don’t need to do that. Add them all to the lvrows array, then call AddRows with the lvrows parameters after the loop. Kill the UpdateBrowser calls.
You may also want to look in to the AddRowSet method, as it could simplify your code significantly as long as the names of your GraffitiGridColumns matches the database table columns.
Thank you for your replies. I have tested all your suggestion but I still have the same issue when my Rowset has 100 columns. I have also changed my code to use preparedStatement to make my query faster but the loop of rowset remains very slow and I believe the issue is there. When this procedure takes more than 15 seconds every browser throws the same exact error. I have tested it on my Macbook Chrome,safari, mozilla plus on my Windows chrome, mozilla. I have decreased my query columns to only the needed ones and the While loop is finishing in 6 seconds which makes everything work. But I am searching if there is a way to make rowset loop faster even with queries with many columns. Thank you again. Your work on Graffiti suite is great.
That’s an extreme number of columns, and is likely the cause. I never recommend more than 15 columns on a Grid, then have a detail view that users can access when interacting with rows to display the rest of the data.
You have to keep in mind the amount of data that you’re sending to each client when you try to load that much information all at once, nevermind the time to render it in the GraffitiGrid.
There’s also a fair amount of data type validation that goes on in the background that’s abstracted away to make sure the data supplied matches the expected type for the column. All of these things make a large set of columns harder to responsibly achieve.