Howdy, Stranger!
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.6K Microsoft Dynamics NAV
- 18.7K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 115 Navision DOS
- 854 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 615 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 305 Dynamics CRM
- 109 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 993 SQL General
- 384 SQL Performance
- 34 SQL Tips & Tricks
- 34 Design Patterns (General & Best Practices)
- Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.7K General
- 1.1K General Chat
- 1.6K Website
- 79 Testing
- 1.2K Download section
- 23 How Tos section
- 260 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions
How to move existing data from C/AL tables to AL tables?
nicolassaleron
Member Posts: 11
Hello,
We have an existing database with customizations developed in C/AL. We have moved the developments to AL on Business Central, thanks to txt2al tool.
And now, we do not know how to handle data...
What would be the "upgrade path" to move custom C/AL table data and custom field data in W1 tables to the all new extension?
Thank you in advance for your ideas.
We have an existing database with customizations developed in C/AL. We have moved the developments to AL on Business Central, thanks to txt2al tool.
And now, we do not know how to handle data...
What would be the "upgrade path" to move custom C/AL table data and custom field data in W1 tables to the all new extension?
Thank you in advance for your ideas.
1
Best Answer
-
TallyHo
Member Posts: 417
Hi,
That will work. But it means copying all table data 2 times,
while the AL and C/AL objects have the same ID.
This is a solution for an extension that upgrades C/AL solutions
that do not contain too much data. A solution that contains
multiple ledger entries and posted document tables could just
take up too much time. But a lot has changed since servers use SSD,
so maybe I'm a bit too skeptical.
Ideally installing the app should rename the existing SQL table to
make it part of the extension.
5
Answers
Using different field or object numbers when upgrading to extensions
is not an ideal solution to me.
Thank you for your answer, I was afraid of that
Currently we think to implement the data migration by following this path:
1. Convert objects and fields to AL with the same IDs. This will be our "Custom Extension"
2. Create a C/AL tables and codeunit to move data to upgrade tables when C/AL tables and fields are removed
3. Create an AL "Data Migration Extension" which has dependency on our "Custom Extension" and then copy data from C/AL upgrade tables to AL "Custom Extension" tables.
4. Delete C/AL upgrade tables and AL "Data Migration Extension"
I was also wondering if RapidStart can make the job on small databases...
That will work. But it means copying all table data 2 times,
while the AL and C/AL objects have the same ID.
This is a solution for an extension that upgrades C/AL solutions
that do not contain too much data. A solution that contains
multiple ledger entries and posted document tables could just
take up too much time. But a lot has changed since servers use SSD,
so maybe I'm a bit too skeptical.
Ideally installing the app should rename the existing SQL table to
make it part of the extension.
https://ricardomoinhos.com/c-side-to-al-table-data-migration/
This is a post from June 2019.
https://ricardomoinhos.com/c-al-to-al-data-upgrade-automation-powershell-script/
And this one is a tool to automate the data migration objects automatically.
Plase let me hear from you. I hope this helps.
Please leave your comments in my website as well.
Regards,
Ricardo Paiva Moinhos