MySQL problems when installing Product File Attachments

If I follow the hints in the Readme.md file, I have no problem to integrate the content of public_html, but afterwards I have to include something in the SQL file starting with phpMyAdmin and the statement "CREATE TABLE IF NOT EXISTS `lc_products_files" and so on.
Of course I have to exchange the letters "lc" for the letters that are in my file before all names. After starting the MySQL query in the program, the new expected line is also present in the file.

After that I quit phpMyAdmin then neither my store nor the admin page is reachable, only empty pages.
With my little knowledge I do not know where to look for the error.

The pages work again when I install the latest update (without the new entry for the module of course). 
But each time (maybe from my hosting program??) the number of the file is changed and thus the access via phpMyAdmin and within in the file the letters before the whole entries.
For me it is also mysterious where the SQL file is at all, because when I look at the directory structure with FileZilla there is no database to see and in the admin area of my site I also find no path to it.

Can someone please tell me where else to look to actually finish installing this module?

I'm sorry I don't fully understand. This add-on does not come with any SQL files. And I don't know what you mean by "the number of the file"? The files with numbers are the upgrade patches of new litecart versions.

There is a MySQL query in the README.md. And it sounds like you have performed the query to produce the database where the attachments will be stored. You did so using phpmyadmin, is that right?

If you have an error message please post it. Look in logs/errors.log for the latest.

If you are locked out try deleting the vMod xml file you uploaded or rename it to product_file_attachments.disabled to disable the add-on.

There I have probably expressed myself again unhappily.
From the hoster's system the SQL database gets a number like db337663x3477649.
The front part is probably the customer number, but the back part after the x changes when I import the backup. And all entries like zd95_products_files are called e.g. wdhg_products_files etc. and these letters are also changed every time.

In the log I found as last entry:

[quote][15-May-2023 22:39:57 Europe/Berlin] Fatal error: 1146 - Table 'db337663x3477650.ur7r_products_files' doesn't exist
select * from ur7r_products_files
where product_id = '80'
order by priority asc, id asc;
 in ~/includes/library/lib_database.inc.php (Line 177)
 ← ~/vmods/.cache/includes-references-ref_product.inc.php (Line 228) in query()
 ← ~/vmods/.cache/includes-references-ref_product.inc.php (Line 33) in _load()
 ← ~/vmods/.cache/includes-references-ref_product.inc.php (Line 39) in get()
 ← ~/vmods/.cache/pages-product.inc.php (Line 121) in isset()
 ← ~/includes/library/lib_route.inc.php (Line 125) in include()
 ← ~/index.php (Line 51) in process()[/quote]

And yes I used using phpmyadmin in the finished database and when entering the part from your readme.md into the query just the entry product_files was added to this file.
But I read the error log as I suspected that the Sytem afterwards after saving / finishing phpmyadmin the whole file no longer finds.

[quote]changes when I import the backup[/quote]
This is probably a feature of your backup software. Turn to your web host to make sense out of this.

[quote]But I read the error log as I suspected that the Sytem afterwards after saving / finishing phpmyadmin the whole file no longer finds.[/quote]
It could be that you have multiple databases and selected the wrong one when running your query. You can find which database and prefix is used in includes/config.inc.php.

[quote]Table 'db337663x3477650.ur7r_products_files' doesn't exist[/quote]
This suggests that the database db337663x3477650 have no table named ur7r_products_files. So wherever you created it, it was not in the application's database.

To run the query in README.md. All you need to do is this:

1. Open phpMyAdmin
2. Select your litecart Database
3. Click SQL tab
4. Paste the query into the textarea and execute it.

Thank you very much for the help.
Now I know at least where the database is in includes/config.inc.php.
I have actually only one database, but by the mentioned joke with each time a new one at Restore, there were several which I then deleted, so that only the last valid one is there.
The integration from the readme.md in phpmyadmin with your instructions also worked well.
But I still can not get back in, although the entries in the config.inc.php recognizably correct.
I can only not read the database password, because that is stored in a different form.

And I'm afraid the reason is the password, because the log now says:
[16-May-2023 14:13:47 Europe/Berlin] Fatal error: Could not connect to database: 1045 - Access denied for user 's337663_3477653'@'sh8-39.1blu.de' (using password: YES) in ~/includes/library/lib_database.inc.php (Line 27)
 ← ~/includes/library/lib_database.inc.php (Line 172) in connect()
 ← ~/includes/library/lib_settings.inc.php (Line 9) in query()
 ← ~/includes/autoloader.inc.php (Line 136) in init()
 ← ~/9483609a73d64d9a/login.php (Line 4) in {closure}()
Request: GET /9483609a73d64d9a/login.php HTTP/2.0

But the database password is stored correctly, otherwise I could not get in with phpmyadmin.
How can I fix this without restoring yesterday's backup in which of course the new entry for the module is missing?

Could not connect to database: 1045 - Access denied for user
Your provided mysql user in config.inc.php does not have access to the stated database in the same config file. Probably because it's a new database and somone did not delegate access  permissions to the mysql user.

Consult your web host for instructions how to use their provided management tools.

Thanks again for the support.
Have now regained access by simply replacing the weird database password in config.inc.php (which I thought was a anyway converted real PW) with my plain text password for the current database.
Didn't work immediately then, as I've sometimes experienced, but 15 minutes later on the next try.
Why some changes have to be updated somehow or by something I don't know, but probably you do.