Announcement

Collapse
No announcement yet.

Import issue from dotNetBB - no date information

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Import issue from dotNetBB - no date information

    I did a couple of test imports from dotNetBB, and all the dates (user join, post, last post in thread, etc.) defaulted to 01-01-1970. Did all the post-import tasks, updating counters, etc. Then tried a third clean import and still had the same problem, so I looked at the imported data and no dates were imported.

    For example in the users table, joindate, lastvisit, lastactivity and lastpost are all "0." The only user with any epoch dates is the admin set up during install. So it would seem obvious that updating counters in a case like this isn't going to fix data that isn't there.

    Is this an issue anyone else has run into? It's kind of a show stopper.

  • #2
    The join date will be an issue, but the others will fix themselfs naturally.

    Comment


    • #3
      If You're talking about lastvisit, lastactivity and lastpost for a user, yes, I suppose they will "fix themselves" (for active users, anyway). But the existing thread and post dates will not fix themselves.

      It would seem to me that something is wrong with the import if every date related to the forum has a value of 0.

      Comment


      • #4
        All posts and threads have the same issue?

        What is the date format for your dotnetbb for your posts/threads?
        Last edited by Zachery; Wed 18th Feb '09, 8:28am.

        Comment


        • #5
          All posts and threads have the same issue. Every date/time field.

          dotNetBB uses a readable date/time in the db: "11/22/2003 10:43:46 AM" as opposed to the epoch date in vB. But I assumed the importer would try to parse/convert them.

          Comment


          • #6
            Yes, ImpEx relies on PHP's strtotime() to parse them and should be fine with that format.

            I'll have to see this in action to figure it out (i.e. start a support ticket and ask for me and link to this thread).
            I wrote ImpEx.

            Blog | Me

            Comment


            • #7
              Thanks Jerry. I opened a ticket earlier today - Ticketid: 895423

              Comment


              • #8
                epoc dates after conversion

                I am running into the same issue where the thread 'last post date' or a user's join date are all appearing as 12/31/1969 11:00 PM. That is probably 1/1/1970 without daylight savings time. This is happening in all threads in all of the forums I imported.

                Was there a resolution to this issue? I can open a ticket if needed. Thanks.

                Comment


                • #9
                  Originally posted by zfi View Post
                  I am running into the same issue where the thread 'last post date' or a user's join date are all appearing as 12/31/1969 11:00 PM. That is probably 1/1/1970 without daylight savings time. This is happening in all threads in all of the forums I imported. <br /> <br />Was there a resolution to this issue? I can open a ticket if needed. Thanks.
                  <br /> <br />

                  Updating the counters, as per the instructions at the top of every impex page.
                  I wrote ImpEx.

                  Blog | Me

                  Comment


                  • #10
                    Originally posted by Jerry View Post
                    <br /> <br />

                    Updating the counters, as per the instructions at the top of every impex page.
                    I completed the import and then ran the 'Rebuild Thread Information" and the "Rebuild Forum Information" from the Maintenance -> Update Counters section of the Admin CP. The Last Post Date and the posting date of the individual messages is still 1/1/1970 12:00. I tried restarting Apache, thinking that it might be a cache issue. But the dates remain. I have the same result after pruging the database and retrying the import. What else can I do to correct the dates?

                    Comment


                    • #11
                      Something else you will want to watch out for (once you get the 1969 dates sorted out - I had to re-do the import a few times to get that fixed) is that the import seems to flip AM/PM on the same date. So if someone made a post in the AM and you answered it in the PM of the same day, your answer will be displayed above the question.

                      I didn't notice this in a thread until after we had made the switch and there was no going back. Fixing those as you come across them is a real pain. I eventually had to close all the imported threads just so people would stop reviving threads that were messed up like that.

                      Comment


                      • #12
                        Thanks for the warning on thread sequencing. The site I am migrating has just under 400k posts in about 30 forums. The sequence issue would have been easy to miss in a sea of data. I have this in my issue in my growing check list. It's not quite to NASA standards - yet.

                        The thing with the dates is strange. Now that I'm away from it, I should just check the data in the vbforum database to see if the corect dates actually made it across. If it worked for you, I must be missing a step somewhere. Thanks again for th eencouragement.

                        Comment


                        • #13
                          It appears that the strtotime() function used to convert the 'dateline' is getting tripped up with the milliseconds portion of the time stamp returned from the MSSQL database. The function returns a non-zero value if I use preg_replace() to strip the milliseconds off of the timestamp. The conversion is still has about 3 hours to go, but I now have time data in the vbforum post and thread tables. I am seeing this issue in PHP version 5.2.6.

                          Comment


                          • #14
                            Interesting. The version of dotNetBB I was migrating didn't break the timestamp down to milliseconds, it only went as far as seconds. But the software was pretty old, I have no idea whether we were running the last version.

                            It took me more than a year to convince the company to switch, and once I started the migration I found myself wondering why I couldn't have just left well enough alone. But I have to say that even taking all the headaches into consideration, the migration was well worth it. And Jerry was very helpful in adapting the script to address problems.

                            Comment


                            • #15
                              There are actually two date/time data types in SQL Server 2005 and before; smalldatetime, which is accurate to one second and datetime, which is accurate to 3.33 ms. For some reason, my dotnetBB database is using the more accurate version. This really could be fixed by specifying a formatted date in the SQL query that pulls data from the dotnetBB database. That way, the rest of the impex wouldn't need to be concerned with date format.

                              We need to get through the migration because the old system is really beating up one of our SQL Server instances. This turns out to be a win-win in that we get a much more capable system and one that is actually supported. I'll keep pressing onward.

                              Comment

                              widgetinstance 262 (Related Topics) skipped due to lack of content & hide_module_if_empty option.
                              Working...
                              X