[ERROR] sqlitebiter gs: OpenError: spreadsheet not found about sqlitebiter HOT 6 CLOSED

I'll close the issue.
Feel free to reopen if you still have any problems about the issue.

from sqlitebiter.

@LewWadoo
Thank you for your report.

I am not sure the root cause for now. I could successfully convert my google spreadsheet with sqlitebiter gs in my environment.
Could you tell me your environments information to understand your situation?:

• Python version
• sqlitebiter version
  • did you installed optional dependency packages for gs subcommand?
• Did you enable Google Sheets API for your credentials?
• spreadsheets you typed (gom, etc.?) actually existed at Google Sheets and readable by Google Sheets API?

from sqlitebiter.

I don't remember, what, how and why I was using sqlitebiter. Since then I don't use it.

from sqlitebiter.

Hi @thombashi, I'm also receiving this error:

sqlitebiter -o sample.sqlite gs <credential>.json <spreadsheet-name>
[ERROR] OpenError: spreadsheet '<spreadsheet-name>' not found
[INFO] converted results: source=0, fail=1

Is there any way to access by URL? I believe gspread and pytablereader both support this?

The sheet just needs to be in the "My Drive" folder, no?

from sqlitebiter.

I figured this out, thanks! I had to share the folder with my service account.

I'd be curious what happens if spreadsheet names conflict though. I would say it would be a bit better to default to using the file key. Would you be open to a PR on this and pytablereader?

from sqlitebiter.

Hi @cdbattags

I'd be curious what happens if spreadsheet names conflict though.

According to the gspread document:

https://docs.gspread.org/en/latest/api.html?gspread.Client.open#gspread.Client.open
If there’s more than one spreadsheet with same title the first one will be opened.

I would say it would be a bit better to default to using the file key. Would you be open to a PR on this and pytablereader?

Surely the above might be better. Fallback to open by title would be ideal when failed to open by key to keeping backward compatibility.
PR would always be welcome.

from sqlitebiter.