or `--command='PRAGMA table_list'`
or
--command='PRAGMA table_list'
《okay I'll give it a go. @ikea.se
Yeah, It has to be something in the script. I've been rebuilding this for a while, and not had this issue in the past @Matt
What throws me off is the script works and rebuilds fine form DBeaver. So smells like a support thing.
Yeah, It has to be something in the script. I've been rebuilding this for a while, and not had this issue in the past @Matt
What throws me off is the script works and rebuilds fine form DBeaver. So smells like a support thing.
《Yeah that passes @ikea.se.
So might be a symptom then...interesting
So might be a symptom then...interesting
《But when I run my large script it comes back with the same error. painful.
I'll try to comment out things again and see what it doesn't like again.
I'll try to comment out things again and see what it doesn't like again.
《Yes that works as well. Lists out the tables in there.
《Hmmm I have created a sub set of the scripts that I'm working with.
I have a list of all the DROP TABLE IF EXISTS,
and a sub set of CREATE table x4.
and I'm seeing the no such table error again.
I assume this is the correct command to see locally?
Because when I check the table_list, it seems like nothing changed.
I have a list of all the DROP TABLE IF EXISTS,
and a sub set of CREATE table x4.
and I'm seeing the no such table error again.
I assume this is the correct command to see locally?
wrangler d1 execute <db> --command='PRAGMA table_list' --localBecause when I check the table_list, it seems like nothing changed.
《Maybe I can DM more details to one of you, and share a little more detail, then come back with a conclusion here?
I don't want to share IP, nor spam this room too much.
I don't want to share IP, nor spam this room too much.
MYes,
--local is local. If you don't pass --local, and run wrangler d1 execute [...] - it runs on the Cloudflare network or "production" to some. If you haven't created that table in prod == you get errors.
《okay cool. So everything I'm doing right now is --local. I do have a production and develop database in the network, and have previously used this method to update them with no issue.
《I did attempt to run ths same script against my development database, and wittnessed the same error I'm getting locally.
《SO at least it's consistent...
MNote that if you're using DBeaver: I don't think it supports D1. Local SQLite != D1. I have a suspicion some of your issues are distinct from D1 itself.
《Right, so the sqlite3 files was originally created with wrangler, but I have been editing it locally using DBeaver, by pointing the connection to ./.wrangler/state/d1/...
So you think DBeaver might have currupted the sqlite3 file in some way? Because yeah, I was just writing a list of things I tried, and there is some odd stuff happening.
So you think DBeaver might have currupted the sqlite3 file in some way? Because yeah, I was just writing a list of things I tried, and there is some odd stuff happening.
《What IDE would you recommend?
《I do have Views, and triggers in this DB too.. I'm assuming that fine, because it all seems to be working.
《So with that train of thought. I removed DBeaver from the process. I delete the local database, and rebuilt it using the same script locally using wrangler only.
Then tried to run the database build script a 2nd time using just wrangler and got the same no such table error.
If I manually drop the tables in the same order as the script attempts, with no 'If Exists' then it works.
If I try to drop the tables in the same order with If Exists is shows the error.
So not sure if that makes sense, but yeah. I wouldn't expect to see that error.
Then tried to run the database build script a 2nd time using just wrangler and got the same no such table error.
If I manually drop the tables in the same order as the script attempts, with no 'If Exists' then it works.
If I try to drop the tables in the same order with If Exists is shows the error.
So not sure if that makes sense, but yeah. I wouldn't expect to see that error.
LHi Matt, yes I am using the original backend since it has back-ups enabled. Is there a migration path planned from the original backend to the experimental backend when backups become available on the experimental as well?
《@Matt Anyway I'll leave this and come back to it tomorrow. Thanks for the help so far. I'll prob come back tomorrow with a solution hopefully. Thanks again
MNot an automated path in the near term (primarily because these are alpha databases, not production databases). You can easily export and then run
execute DB_NAME --file=export.sql to import your old database.MI'd suggest opening an issue on GitHub — I think we have exhausted debugging here via Discord without seeing your SQL. I really suspect your migration/seed scripts are just not creating the right tables first.
LThis will sound really dumb but, how do I export my database using Wrangler?
LThanks nora!
Just FYI, in case someone else runs into a problem that I ran into during the process:
On windows, after converting the backup to a sql file using sqlite3 (using sqlite3 <path-to-downloaded-file> .dump > latest.sql) when attempting to import via npx wrangler d1 execute <name> --file=latest.sql, wrangler was complaining about an imaginary synthax error like this:
near "��P": syntax error [code: 7500]".
It turns out this is an encoding problem, the sql file ended up encoded in UTF-8-BOM and had to be converted to UTF-8. You can do this using Notepad++ via the Encoding menu option and then saving. After which, the import worked flawlessly (18MB database imported in about 30 seconds or so)
Just FYI, in case someone else runs into a problem that I ran into during the process:
On windows, after converting the backup to a sql file using sqlite3 (using sqlite3 <path-to-downloaded-file> .dump > latest.sql) when attempting to import via npx wrangler d1 execute <name> --file=latest.sql, wrangler was complaining about an imaginary synthax error like this:
near "��P": syntax error [code: 7500]".
It turns out this is an encoding problem, the sql file ended up encoded in UTF-8-BOM and had to be converted to UTF-8. You can do this using Notepad++ via the Encoding menu option and then saving. After which, the import worked flawlessly (18MB database imported in about 30 seconds or so)
LIs there a rough estimate regarding enabling backups on the experimental backend?
This backend is significantly faster, event without indexes, but I am reluctant to using it until I have backups running.
This backend is significantly faster, event without indexes, but I am reluctant to using it until I have backups running.
C
LThanks @Cyb3r-Jok3 Time travel seems super cool, but so far when following the blog post and trying stuff out (like this wrangler d1 time-travel info YOUR_DATABASE) I get [ERROR] Unknown argument: time-travel. I am using wrangler 3.2.0
CI believe you need to be using the
d1 release of the wrangler branch as it hasn't been merged into a release yet. If you do npx wrangler@d1 d1 time-travel info <db> then I believe it should workLJust tried, it seems to not be working as of now . Unless I am doing something really wrong 
npx wrangler@d1 d1 time-travel info <db>
X [ERROR] Unknown arguments: time-travel, info
npx wrangler@d1 d1 time-travel info <db>
X [ERROR] Unknown arguments: time-travel, info
LDoes D1 database have limit on how many tables you can create?
MDouble check you have the latest
wrangler@d1 branch. It definitely works. I am using the same public version as everyone else. But also note that this isn’t final - I’d suggest holding off until we officially release it if you rely on your database.M
EHello, I've been digging through chat and the documentation to look for a way to use D1 with
For SvelteKit specifically, it looks like the
That may eventually be addressable through the adapter. This would be great to have to improve the developer experience.
Could I be missing something meanwhile? The docs mention a
vite dev and the best I could find is re-running the production build. https://discord.com/channels/595317990191398933/1042974692186804295/1048148731670835290For SvelteKit specifically, it looks like the
platform parameter needs to be able to receive the D1 client library when developing locally: https://github.com/sveltejs/kit/issues/4292That may eventually be addressable through the adapter. This would be great to have to improve the developer experience.
Could I be missing something meanwhile? The docs mention a
--d1 flag to set up the database binding locally, but I assume that's for the wrangler CLI and not Vite.
MIf you don't inject the binding into the application - vite or not - you won't be able to access the local DB. The flag — the binding — is what allows your app to talk to D1. Think of it like a DB driver = without it, there's no way for your code to talk to the DB. In lieu of that, you can see that others are mocking the
platform object and the APIs they need.
Chow do I drop a 
DEFAULT constraint? 
MM
CI have some workers routes defined in my
when I print the login url (using Hono via
Locally though, with
wrangler.tomlwhen I print the login url (using Hono via
c.req.url) I correctly get https://foo.com/login when it's deployed to Cloudflare.Locally though, with
wrangler dev , I get http://send/login - it seems to be using the first route as the hostname, which is bizarre. Is this is known issue?
MMthis is now live
CI've reported and added a little more information, specifically that commenting out the wildcard route definitions makes it work as expected locally, but those are required for production.
https://github.com/cloudflare/workers-sdk/issues/3635
https://github.com/cloudflare/workers-sdk/issues/3635
GitHub
Which Cloudflare product(s) does this pertain to? Wrangler core What version(s) of the tool(s) are you using? 3.3.0 What version of Node are you using? No response What operating system are you usi...
Mcheers - btw #wrangler might be a better place to ask folks if they've run into this issue
CGreat, thanks for the tip
COnly just realised I posted this in the D1 channel - sorry! Must've hit the wrong tab when aiming for wrangler (immediately above it)
Mnah the idea is to keep them around so you can setup the project from scratch
Md1 keeps track of what you're already applied, but if you made a new db you could apply all migrations from the start and have a working copy
Myep
