Open lucaato opened 3 years ago
Seconding this. I had the same issue doing a clean install of a standalone instance, then backing up my notes from a previous instance via the webapp and restoring them.
Hi, a simple workaround if you have just one user is to use the export feature in the standardnotes app (on windows is under Account>Data Backups). You have to start with exporting the notes from the app, after that create the new standardnotes stack with compose, recreate an empty account by registering and then reimport all the notes from the app. After that you will have to set the DISABLE_USER_REGISTRATION property to true if you don't want anyone else to register.
However this is not doable with more users.
I believe that's the exact process I went through. I was running an older
version of the syncing server and had to do some work on the database to
get the newest version to import from my dump. Eventually I got a
mostly-working version and was able to use app.standardnotes.org to export
via the process you described. I ran server.sh cleanup
on the new
instance, removed dbdump.sql from the import directory, and started a fresh
server. I tried importing the exported file and it mostly worked but
resulted in the same error described by the OP. I'll be interested to see
whether this workaround works for OP...
On Thu, Aug 12, 2021 at 11:37 AM Luca @.***> wrote:
Hi, a simple workaround if you have just one user is to use the export feature in the standardnotes app (on windows is under Account>Data Backups). You have to start with exporting the notes from the app, after that create the new standardnotes stack with compose, recreate an empty account by registering and then reimport all the notes from the app. After that you will have to set the DISABLE_USER_REGISTRATION property to true if you don't want anyone else to register.
However this is not doable with more users.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/standardnotes/standalone/issues/38#issuecomment-897742007, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKQOS3SXRECQCRGUZJL56LT4PTDFANCNFSM5BYTJG6A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .
Wait! Sorry. I didn't realize the workaround was suggested by the OP! I'm surprised that worked for you!
Maybe if I try exporting again from the imported data it'll work better?
On Fri, Aug 13, 2021 at 2:06 PM Zack Panitzke < @.***> wrote:
I believe that's the exact process I went through. I was running an older version of the syncing server and had to do some work on the database to get the newest version to import from my dump. Eventually I got a mostly-working version and was able to use app.standardnotes.org to export via the process you described. I ran
server.sh cleanup
on the new instance, removed dbdump.sql from the import directory, and started a fresh server. I tried importing the exported file and it mostly worked but resulted in the same error described by the OP. I'll be interested to see whether this workaround works for OP...On Thu, Aug 12, 2021 at 11:37 AM Luca @.***> wrote:
Hi, a simple workaround if you have just one user is to use the export feature in the standardnotes app (on windows is under Account>Data Backups). You have to start with exporting the notes from the app, after that create the new standardnotes stack with compose, recreate an empty account by registering and then reimport all the notes from the app. After that you will have to set the DISABLE_USER_REGISTRATION property to true if you don't want anyone else to register.
However this is not doable with more users.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/standardnotes/standalone/issues/38#issuecomment-897742007, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKQOS3SXRECQCRGUZJL56LT4PTDFANCNFSM5BYTJG6A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .
@luca-a it seems like the issue is cause by invalid SQL data in the dump.
seems like you have some odd records in the settings
table.
This is the faulting query:
INSERT INTO `settings`(`uuid`, `name`, `value`, `server_encryption_version`, `created_at`, `updated_at`, `user_uuid`) VALUES (?, ?, ?, ?, ?, ?, ?)',
parameters: [
'stringParameter',
'stringParameter',
'stringParameter',
0,
,
,
'stringParameter',
]
Would it be possible for you to edit the sqldump file and remove that settings
entry from there and trying to reimport the database backup?
Describe the issue Hi, I've dumped my legacy db as described in https://docs.standardnotes.com/self-hosting/legacy-migration/. After doing so I've created my stack by following a similar procedure to the one described on the website. If I create a new db everything works fine, Instead if I place my dbdump.sql in the import folder I get this error in the auth container.
Service Versions:
Logs Logs of the auth container which seems to be the one that's causing the problem:
I've replaced string parameters of the query with the string
'stringParameter'
since I don't think that's the problem and also because I don't want to risk leaking relevant account data. 😁To me it looks like there is an error in the not null constraints of the table or maybe the software is passing a null parameter where it shouldn't.
I hope someone can help me figure it out. Thanks in advance.
If needed I can give more info about the setup I'm using.