Hi Bruce
C-tree tables in the local workstation's temp folder are used for ctree temp tables (as opposed to SQL temp tables) and for "Memory" tables.
The reason we (developers) use them is that they can be much faster than SQL temp tables, which have an overhead to create and destroy.
They are excellent for fast access to small amounts of data.
They should NOT be used for large amounts of data as that can be slow to populate the table and can risk running out of memory. In this situation, a SQL Temp table should be used as the SQL server should have the space needed. Also SQL can copy data from SQL tables to SQL Temp tables very quickly using pass through SQL commands like SELECT INTO or INSERT.
They should NOT be used for reports as this force the Report Writer to read everything record by record and swap between ctree and SQL tables. If all tables used on a report are SQL based, Dexterity will use a single SQL Select statement with joins to pull in the data and will be much faster.
If they HITB reports are using a ctree temp table, I would log that as a bug to be fixed.
David
------------------------------
David Musgrave MVP, GPUG All-Star
Managing Director
Winthrop Development Consultants
Perth, Western Australia
http://www.winthropdc.com------------------------------
Original Message:
Sent: 02-16-2017 09:05 AM
From: Bruce Strom
Subject: Is there a technical explanation why you don't VPN connect to GP
David Musgrave,
I have a question relating to running Great Plains on a Citrix network.
We are running GP2010, we are in the process of upgrading to GP2016.
When we run very large reports off our large data set, particularly the HATB reports,
sometimes we encounter a disk space error relating to temp files.
For many report writer reports Great Plains builds temp files before running the report.
Most of these temp files are cTree files created on the "local" machine, not the SQL server,
and in a Citrix environment "local" means the Citrix metaframe server.
Do you think Great Plains will ever get away from using cTree temp files?
Or maybe they would rather crash the local workstation rather than filling the SQL log files, crashing the SQL server.
Thanks,
Bruce
------------------------------
Bruce Strom
Programmer Analyst
Associated Grocers of Florida
sunrise FL
------------------------------
Original Message:
Sent: 02-13-2017 02:02 AM
From: David Musgrave
Subject: Is there a technical explanation why you don't VPN connect to GP
Hi Tim
I was about point you to my article, but you found it already.
This article was written while I worked for Microsoft after we had a number of support cases from an Indonesian customer where they were trying to implement Dynamics GP over a WAN without using Terminal Server/Citrix and were having data corruption and performance issues.
David
------------------------------
David Musgrave MVP, GPUG All-Star
Managing Director
Winthrop Development Consultants
Perth, Western Australia
http://www.winthropdc.com
------------------------------
Original Message:
Sent: 02-10-2017 07:03 PM
From: Tim Andaya
Subject: Is there a technical explanation why you don't VPN connect to GP
I think I found the type of answer I was looking for
Why can't I run Microsoft Dynamics GP via ODBC over a WAN?
| Developing for Dynamics GP |
remove preview |
|
| Why can't I run Microsoft Dynamics GP via ODBC over a WAN? |
| I had an interesting support case last week where the partner was asking why running Microsoft Dynamics GP via ODBC over a WAN was so slow? They had already told the customer that this was not supported, but the customer wanted reasons. Below is my response: I should start off saying that we definitely do... |
| View this on Developing for Dynamics GP > |
|
|
------------------------------
Tim Andaya
Strategic Systems Group
Thousand Oaks CA
---
I'd rather have you mad at me for telling you something you did know than for not telling you something you didn't.
------------------------------
Original Message:
Sent: 02-10-2017 05:20 PM
From: Rob Klaproth
Subject: Is there a technical explanation why you don't VPN connect to GP
ABSOLUTELY. A VPN connection is going to have a latency of 30-40ms on a west coast to west coast connection and 60-80ms on a west to east connection. This latency is enough to cause an issue with using the GP thick client. It was not designed to work on anything other then a LAN. And users on the LAN should use it on a hard wired connection, not wi-fi.
You are best served by using a terminal server to allow the remote users access to GP.
------------------------------
Rob Klaproth
Sr. Dynamics GP Consultant
Armanino
San Diego CA
------------------------------
Original Message:
Sent: 02-10-2017 05:14 PM
From: Tim Andaya
Subject: Is there a technical explanation why you don't VPN connect to GP
Yes, I know, it's a bad idea but one of our client's IT department moved their GP server to a collocation facility and now the heavy client performance is suffering tremendously while the web client connections didn't even blink.
We have explained to them that they should run the client from a terminal server at the collocation facility but the IT department states that the users won't do it.
The IT department wants a technical explanation of why they are seeing such a dramatic performance difference when they have large throughput capacity at both the collocation facility and the corporate office.
Does anyone have a technical explanation?
I have a theory but, they didn't like it and want something better.
Thank you.
------------------------------
Tim Andaya
Strategic Systems Group
Thousand Oaks CA
---
I'd rather have you mad at me for telling you something you did know than from not telling you something you didn't
------------------------------