Luegisdorf
12/9/2005 12:27:00 PM
Hi Mike
Thank you for your answer. That's exactly what I've analyzed too.
At moment I work this way:
// server class method
....
while select tmpTable
{
clientClass.createBuffer(tmpTable);
}
....
// client class method
createBuffer(Common _tmpTable)
{
tmpClientTable.data(_bufferFromServer);
tmpClientTable.insert();
}
Unfortunelly the time factor takes effect and sometimes axapta crashes
proceeding the 'while select'. May be I can do something with a
RecordInsertList ...
I will keep you informed about the results. And to all other news group
user: If you have a working solution, please provide.
Best Regards
Patrick
"Mike Frank" wrote:
> Hi Patrick,
>
> Consider the following quote from developer guide. I made some experiments around this and was not
> able to move the file to the other tier. It always stays where it was created. (see code fragments
> below)
> I noticed also some interesting side issue. There was not always a file create. Only if a certain
> amount of memory was consumend by the temporary table (Number of records + number of fields had an
> effect).
>
> So you would just pass your buffer to your client method. It certainly depends on how much records
> it contains. If there are lots of records, you could consider to copy only the records needed at the
> client to a second buffer and pass this to the client. Though I'm not sure how this buffer passing
> between client and server is done by the kernel, probably like for ordinary buffers (see second
> developer guide quote). You would have to make performance tests to be sure.
>
> ====================================================================================================
> Temporary tables are instantiated and "live" where data are first inserted. The first insert
> determines whether a table lives on the client or on the server. So it does not matter where, on the
> server or on the client, a temporary table is declared. Even when you write code like server static
> <tmptable>::createTable() that instantiates a table, the table still becomes a client temporary
> table if the first record is inserted from client code.
>
> If a temporary table has a new dataset (setTmpData), the temporary table will afterwards live where
> the temporary table it's having it's data from are living.
>
> Hints
> A temporary table should live on the tier where it is used.
>
> If a temporary table is used on several tiers, the table should live on the tier where the largest
> number of inserts and updates is performed.
> ====================================================================================================
>
> public static client void Main(Args args)
> {
> TmpBOM tmpBOM;
> ;
> // the same behaviour with both statements
> //tmpBOM.setTmpData(CbsTestTmpTable::createTempTable());
> tmpBOM = CbsTestTmpTable::createTempTable();
>
> select tmpBOM;
>
> info(tmpBOM.ItemId);
> }
>
> public static server TmpBOM createTempTable()
> {
> TmpBOM tmpBOM;
> int i;
>
> for (i = 1; i <= 768; i++)
> {
> tmpBOM.ItemId = strfmt("Item%1", i);
> tmpBOM.Level = i;
> tmpBOM.Qty = 25* i;
> tmpBOM.insert();
> }
>
> return tmpBOM;
> }
>
> ====================================================================================================
> Record buffers are automatically replicated between server and client when needed.
>
> The system will replicate a buffer between client and server, as program controls flows between
> client and server, and the buffer is needed. For the application programmer it will look like the
> buffer is always directly available, and table instance methods can be set to client or server based
> on their functionality, rather than on where their objects are living.
>
> As the system replicates the buffers as needed, client/server traffic increases, and it will take time.
> ====================================================================================================
>