If you live outside the United States, by submitting your email address you consent to having your personal data transferred to and processed in the United States.
If it’s a SQL database on the AS/400, no tools are needed other than SQL on both platforms. But if it’s a native database, there might not be a good conversion possible without significant rewrites. There are various elements in native DB2 that simply don’t exist in SQL Server nor in any other SQL database. A “tool” is unlikely to do much of the work for non-SQL features. So, in order for anyone to give suggestions that fit, you’ll need to give a reasonably complete overview description of the database. How many PFs? How many LFs? How many of the LFs are used for views, for indexes and for both? Any multi-member files? (How many?) Any referential or integrity constraints or triggers? Any uses of OPNQRYF? If so, do any generate dynamic indexes? If so, are any keys split across multiple tables? How much maintenance is done through native I/O with native programming rather than SQL? (Include descriptions of CHAINs and SETLLs, for example, to secondary tables.) Bear in mind that such maintenance has historically been in native code rather than through database interfaces (SQL, database rules, etc.) To know of tools that might fit, it’s necessary to know what the tool must fit with. — Tom
When you say migrate data are you saying you are moving you application from AS400 to an SQL Server. If so, why are you doig that, & have you looked at the total expense of such a project? Most places that have done that end up spending far mor $ that they expected and may just come back the the AS400.
If it’s a SQL database on the AS/400, no tools are needed other than SQL on both platforms. But if it’s a native database, there might not be a good conversion possible without significant rewrites. There are various elements in native DB2 that simply don’t exist in SQL Server nor in any other SQL database. A “tool” is unlikely to do much of the work for non-SQL features. So, in order for anyone to give suggestions that fit, you’ll need to give a reasonably complete overview description of the database. How many PFs? How many LFs? How many of the LFs are used for views, for indexes and for both? Any multi-member files? (How many?) Any referential or integrity constraints or triggers? Any uses of OPNQRYF? If so, do any generate dynamic indexes? If so, are any keys split across multiple tables? How much maintenance is done through native I/O with native programming rather than SQL? (Include descriptions of CHAINs and SETLLs, for example, to secondary tables.) Bear in mind that such maintenance has historically been in native code rather than through database interfaces (SQL, database rules, etc.) To know of tools that might fit, it’s necessary to know what the tool must fit with. — Tom
In most cases, it’s simple to move the physical files and data.You will not be able to convert the programs.
When you say migrate data are you saying you are moving you application from AS400 to an SQL Server. If so, why are you doig that, & have you looked at the total expense of such a project? Most places that have done that end up spending far mor $ that they expected and may just come back the the AS400.