Showing contents of a temporary record variable

petevans

Hiya.

I am writing a dataport which will perform relatively large changes to many accounts, and I would like to be able to test the changes before I do them, so to speak.

I created the dataport with temporary records and have weeded out the ERROR's without making actual changes to the DB, but I would like to see what my records look like as well.

I was hoping I could just use (Form).SETRECORD(myTempRec), but that only shows data from the original table. Bummer!

I could write to file I suppose, but I am wondering what the rest of you usually do to visualize changes before they are commited to the DB? Any tips on how to do this easily?

matttrax

Why not just do it in a test database?

If you can't do that then copy the original data to a new table and test with that.

petevans

Hi, thanks for your reply.

I am doing it on a local test DB, but the problem is if I commit the data and it makes a whole lot of changes - some right and some wrong, then I have messed up my test data.

I suppose I could make another dataport and export and import my test data every time I want to make a test run, but it seems rather tedious.

petevans

Oh yeah, and my test data is in several different tables. Dimensions, G/L Accounts, G/L Entries, etc. So even more tedious

matttrax

You can run forms on temporary tables, but I don't think you can do it in the way you want to.

Just make new tables. You can do your analysis on the real data, but instead of modifying the data in the real tables insert the new data into the new tables. Then you can run a form on it. If it's wrong you just delete the fake data and start over.

And I really hope you're not creating a dataport that modifies G/L Entries. [-o<

petevans

Yeah it's just a bit of a hassle to create new tables with the correct table relations and everything. I was just hoping that there was a quick way to show the contents of a temporary record.

Thanks for your replies though, it's helpful to know there isn't a secret easy way that everone knows of but me at least . Maybe I could make some file export functions I can easily reuse...

As for the G/L Entries, they are just moved to a newly created account. So the only thing that changes in the entry is the Account No. and Project dimension. People around here seem to be OK with it.

matttrax

petevans wrote:

Yeah it's just a bit of a hassle to create new tables with the correct table relations and everything.

Design the original table, File --> Save As. Give it a new ID and a new name.

petevans wrote:

As for the G/L Entries, they are just moved to a newly created account. So the only thing that changes in the entry is the Account No. and Project dimension.

Moved as in the Account No. is changed? Or moved as in you do a General Journal and take the exact sum out of the original account and into a new account (this two new G/L Entries)?

Shouldn't they be posted to the right account with the right dimensions the first time?

petevans wrote:

People around here seem to be OK with it.

Just because the customer is ok with it doesn't mean it's good or correct. What if it's an entry for a credit only account and you change the account number to a debit only account? Or numerous other things. This is going to come back to bite you.

petevans

Design the original table, File --> Save As. Give it a new ID and a new name.

Hmm yes, but with alot of code in table triggers touching into other tables through OnDelete, OnRename, OnModify, I have tried to avoid this. But maybe I am overestimating the problems related to this. I'll keep it in mind.

As for the G/L Entries, I meant moved as in Account No. is changed. It's a company merger and the companies are creating a new and joint chart of accounts.

After the changes made by this process I am making, the accounts will be examined and controlled by customer/consultant. As for people being OK with it, I didn't just mean the customer, but more importantly other consultants/developers in my company with more experience than me.

Thanks again though, I will make them aware of your concerns.

SPost29

Why not create a single instance code unit with temporary tables in it.
Load those tables from your dataport
then create forms that look at the data iin the tables in the codeunit
Steve

PeterD

What about FORM.RUN(Form#, myTempRec)?

David_Singleton

matttrax wrote:

petevans wrote:

People around here seem to be OK with it.

Just because the customer is ok with it doesn't mean it's good or correct. What if it's an entry for a credit only account and you change the account number to a debit only account? Or numerous other things. This is going to come back to bite you.

Mattrax is dead right, this really is the wrong way to do this. Import GL journals and post using the Navision posting routines. You can't just take entries from one DB and move them into another.

If you ABSOLUTELY decide you must go this route, then please keep my contact details and pass them on to the Financial controller in the company. I do a lot of repair work for companies that have done this sort of thing, so next year when they realize it was a mistake they can call me to fix it.

petevans

PeterD: Nice, FORM.RUNMODAL works!

// Shows original table without changes:
myChart.SETRECORD(tmpGLAcc);
myChart.RUNMODAL;

// Shows temporary table with changes:
FORM.RUNMODAL(FORM::"Chart of Accounts", tmpGLAcc);

I don't understand why there should be a difference, but I am just happy to have an easy way of showing the contents of a temporary record

I also just remembered that if you run a dataport with CTRL+R while in designer, the changes won't be committed (barring an explicit COMMIT in the code), so that's at least a way of running through a large modifying process in "safe" mode.

Thanks to everyone for your help. I have solved all my original problems, and gotten some financial advise to boot

mattrax and Singleton: I have let the more senior consultants/devs who specced this assignment to me know of your concerns, and have advised them to listen to you. And if they don't, I'll give them your number, David