Hello Alex!
OK. I have tried like before but no sucess. Following are the errors:
Import error: Warning: Custom import column `Users.User' had no destination equivelant. A column will be created
Import error: Warning: Custom import column `Users.Pass' had no destination equivelant. A column will be created
Import error: CRITICAL ERROR OCCURED: Unable to execute query `SELECT Username, Password, Email, Validation, Status, User, Pass, Pass, User FROM Users': Table 'Database.Users' doesn't exist at /usr/.../Import/S1S2.pm line 282
What it does is simply creating two columns User, Pass in the table and crashes. Here there is no control as to which field goes where. Table.Validate has all the data that needs to be distributed into different tables in Links SQL v2.0 and therefore this would be necessary.
What I meant was that if in the import routines if one could select fields and either delete or rename them then it can function. I mean otherwise it does what may be unwanted. For e.g. earlier there was User + Pass in the Links1.Validate and now Username + Password table. So what it will do is create and bring the data with the same Properties to the new table. The custom_new table created by import.cgi may not have the same properties as the default_new. This would also be in a conflict with the INDEXES.
Almost everyone has customized their tables and hence an import utility that functions is therefore an acute necessicity.
OK. I have tried like before but no sucess. Following are the errors:
Import error: Warning: Custom import column `Users.User' had no destination equivelant. A column will be created
Import error: Warning: Custom import column `Users.Pass' had no destination equivelant. A column will be created
Import error: CRITICAL ERROR OCCURED: Unable to execute query `SELECT Username, Password, Email, Validation, Status, User, Pass, Pass, User FROM Users': Table 'Database.Users' doesn't exist at /usr/.../Import/S1S2.pm line 282
What it does is simply creating two columns User, Pass in the table and crashes. Here there is no control as to which field goes where. Table.Validate has all the data that needs to be distributed into different tables in Links SQL v2.0 and therefore this would be necessary.
What I meant was that if in the import routines if one could select fields and either delete or rename them then it can function. I mean otherwise it does what may be unwanted. For e.g. earlier there was User + Pass in the Links1.Validate and now Username + Password table. So what it will do is create and bring the data with the same Properties to the new table. The custom_new table created by import.cgi may not have the same properties as the default_new. This would also be in a conflict with the INDEXES.
Almost everyone has customized their tables and hence an import utility that functions is therefore an acute necessicity.
