Pass Temporary record to form

Fisherman

I've looked online and searched the forum, and haven't found anything on this.

Is it possible to pass a temporary record to a form?

I have a form , let's call it Form 50001 "TestForm". I have a Temporary Record variable "X". let's say it's from table 50001.

I insert some records into X (I've verified that they are there through the debugger).

I set the Source property on the form to Table 5001, and call

FORM.RUNMODAL(FORM::TestForm,X)

when the form opens, it's blank. I put a message in OnActivateForm to display the record count, and it's coming back as zero.

I then tried to pass it in more explicitly by creating a form variable "Worksheet", and adding a trigger to the form to copy the temp variable into Rec, like so:

SetWorkRecords(VAR WorkLines: Record 50001)
   Rec.COPY(WorkLines);

still no go. Is this even possible?

kine

I think that the behavious may be different for some versions of NAV.Which version you are using?

Fisherman

Sorry - should have said that.

This is on v5.0, SP1.

I know that 4.0 didn't support this, but 5.0 has that property (SourceTableTemporary) that I've tried, too...

garak

set the property Temporary of the recordvariable to YES.
make your modifications like:

Item.init;
Item."No." := 'fff';
Item.Description := 'fdsswgffs';
Item."Base Unit of Measure" := 'STCK';
Item."Inventory Posting Group" := 'hs';
Item."Unit Price" := 34;
Item.insert;

Form.runmodal(30,Item);

Regards

Fisherman

It already is set to Temporary in the caller.

this is even stranger.

I'm in the debugger. The record in question has values in it - I can see them in the object viewer, but when I call FIND('-') on it, it tells me that the record variable is empty??!

kine

If you set some record variable as temporary, the table will be empty even if there are records in the real table.

Fisherman

kine -

Sorry if I'm not being clear, or am misunderstanding you.

This table never has permanent values. I'm using it as temporary storage only for some staging records that result from a transformation of transactional values.

I'm using it as a temporary record because I don't want any values to ever persist in this table - only to be present during the time in which the user needs them.

In other words, I have a codeunit that takes information from our transactional tables, transforms it into this new table schema, stores the results in a temporary, and I want to display that on screen.

I can see the values in the record variable in the debugger, but calls to FIND('-'), COUNT, and COUNTAPPROX all tell me that there are no records...

Fisherman

Well... for whatever reason, it appears to have something to do with passing a temporary record as a reference variable (VAR).

I was delegating responsibility for transforming child records out to a codeunit that I had already created from a new one that looped through parents.

So if you imagine a typical parent-child relationship, then for every parent record, I was calling the codeunit that handled the children. That codeunit already had a temporary record to store the transformations from child to "staging".

I went into the child codeunit and created a new trigger called "GetWorkLines" that accepted a temporary VAR record as an argument. Inside of that new trigger, I was calling copy like so:

Parameter.COPY(Staging)

What I was trying to do was get the complete set of staging records back up to the parent (calling codeunit) so that i could call FORM.RUN with those records. needless to say... it didn't work.

I did find that I was able to call FORM.RUN inside of the child codeunit, without passing the records back, and it works just fine. Don't know what's going on there, but I'm moving on.

Thanks.

David_Singleton

Fisherman wrote:

Sorry - should have said that.

This is on v5.0, SP1.

I know that 4.0 didn't support this, but 5.0 has that property (SourceTableTemporary) that I've tried, too...

Actually this has been supported on all versions of NAV. The only change in 5 was that instead of having to call the form from code, you can do it with a property, but the functionality is identical.

Fisherman

Interesting. I didn't realize that. I had read on another site that the SourceTableTemporary property had been introduced with v 5.0. I guess that was bad info.

Thanks, David.

kine

1) COPY function will not copy the data! It will copy only filters. If you need to copy data, you need to use loop and insert the record one by one into the second variable!
2) About the SourceTableTemporary - this property replaced the need of defining code in OnFindRecord and OnNextRecord on the form when you want to display temporary table filled in on the form }the rec is not passed when calling the form, e.g. because the form is called from button through the RunObject property or in another way). But in both versions, if you pass temporary table during the FORM.RUN(MODAL) function, both will display this temporary table.

garak

like i wrote in the source above ;-)

David_Singleton

kine wrote:

2) About the SourceTableTemporary - this property replaced the need of defining code in OnFindRecord and OnNextRecord on the form when you want to display temporary table filled in on the form ...

Not exactly. The property replaces the need to call the form modally by passing a TempRecord. It makes it slightly simpler to manage in SOME cases. It does not replace the onfind/onnext. That is different functionality and used for different purposes.

In once case you are using the source record (the temp table) as the source record, and thus are able to use all standard features (sort; filter etc) when using onfind/onnext you are using completely different records for the form and the controls on the form.

kine

Hmmm... yes... true... :whistle:

Fisherman

kine/garak -

Thanks. I must have missed that earlier. I'm assuming that TRANSFERFIELDS can also not be used to quickly copy values between records of the same type?

David_Singleton

I only wanted to clarify this, since many people think that using a TEMP table as the source table for a Form is a new feature, which of course it is NOT, and has been available since the beginning. New is just a simpler way to implement the feature.

kine

Fisherman wrote:

kine/garak -

Thanks. I must have missed that earlier. I'm assuming that TRANSFERFIELDS can also not be used to quickly copy values between records of the same type?

No, TRANSFERFIELDS is there to copy fields between two different tables, not to copy records...

Fisherman

K.

Just another shortcoming in C/AL.

It's not such a big deal in my table, because it's small, but in a large table? I wouldn't want that job [-(

Seems like a reasonable command to add to the language...

kine

I am happy that it is not there. Can you imagine to call this "simple" command to table like G/L Entry? In this way, developer have bigger chance to understand that copying the records can take some time... 8)

David_Singleton

8><

---

<deep breath count to ten 1 .. 2 .. 3 .. 4 .. 5 .. 6 .. 7 .. 8 .. 9 .. 10 ....

relax it's not my problem anyway...>

garak

David .... be cool ....

David_Singleton

garak wrote:

David .... be cool ....

That's a bit hard with some of the posts we are seeing, but I will try. 8)

I am thinking now I need to just sit back, take a one year sabbatical, and when I come back I am going to be inundated with work fixing Navision projects gone wrong. :whistle:

garak

David Singleton wrote:

I am thinking now I need to just sit back, take a one year sabbatical, and when I come back I am going to be inundated with work fixing Navision projects gone wrong. :whistle:

:-D This saves our job, to optimize customer databases :-D :-D.

But i can understand you, some posts are very ](*,) . The problem here is only: the basics are missed by some users .... but they can learn, and a forum can be better then a book ....

Regards

David_Singleton

garak wrote:

The problem here is only: the basics are missed by some users .... but they can learn, and a forum can be better then a book ....

The problem goes far far deeper than that. You are looking at these issues as programming issues. But the issue is a clear understanding of the business need. We are seeing a lot of so called "helpful" posts because they tell the original poster the answer they want to hear. But sometime the best answer is not the one the poster wants to hear. If we as a community give them the code to screw up their customers database then we are just as culpable as the programmer that thinks of them self as a consultant.

If a developer is clearly in over tehir head, and trying to solve a problem the wrong way, we should tell them to go back to grass roots and start again, sit with the consultant and tell the consultant that the analysis is wrong. And the consultant should tell the client that they need to rethink.

SO please next time anyone answers a question by posting some code. Think very careful if maybe we are in fact doing an injustice to the client. I know that sometimes its good to be the percieved nice guy and just say yeah sure, try this code it will do what you want:

GL.Entry.setrange("document No.",'BAD JOURNAL');
GL.Entry.deleteall;

sure you are the nice guy, the poster thinks you are a guru and he is happy, and you get extra points. But is it really the right thing to do?

garak

David Singleton wrote:

But is it really the right thing to do?

With this example really not. I know what you are mean.

Fisherman

David -

I understand what you mean with the DELETEALL() command. Possibilities for large delete batches leading to performance degradation, possibilities for unintended data loss, possibilities of orphaned records if the delete is forced, but you have to understand that I come from the world of Higher Level Languages (C++, VB.Net, C#, JAVA), where it is quite common, and much more optimized, to perform a copy of an entire complex object into another one. C++ even allows you to overload basic operators ("=","+=","-=") for this specific purpose.

What I don't understand is how your comment about DELETEALL() corresponds to my assertion that C/AL should offer a function to copy one record variable into another of the same underlying table. Whether it does or not, an idiotic programmer can still write a copy loop or copy function and screw up their database just as much as if they didn't have the command. Dumb programmers are just dumb programmers, and will find dumb ways of screwing up their systems no matter how much you try to protect them.

Dumb/inexperienced programmers should never limit a language's capabilities. It is their responsibility to learn how to use the language appropriately.

Am I missing something here?

Fisherman

Apologies to all.

I don't see a smiley for "EggOnFace", so I guess :oops: will have to do.

I was confused when the comment was made that TRANSFERFIELDS would not transfer data between two records for the same table. I've since been advised differently, and have tested it to verify. It seems that C/AL DOES offer this functionality, but there is obviously a short between the keyboard and the floor.

David_Singleton

Great to see you got the solution.