I have the following problem:
During archive import through tools I encounter the following error:
An error has occurred preparing a Sql statement.
Please continue or ask your systems administrator to check your application configuration if the problem persists.(SBL-DBC-00108)
ORA-00904: "T3"."SYNC_SUCCESS_FLG": invalid identifier
I looked at the logs T3 is S_EMP_PER table, and "SYNC_SUCCESS_FLG" does not even exist in this table. I don't know why it is referencing this column.
How could I resolve this problem? Thanks in advance.
Most probably, the SIF file came from a different version of Siebel, different from the one you are importing into. Or it could be that the table S_EMP_PER is also modified in your project, you may have to get a SIF of the table and import it first, before you import the BC SIF.
Related
I'm working on a Django Project with Wagtail which uses two databases. The first one is the standard sql lite database for all django models (called db_tool.sqlite3), the other one is also sql lite but for a wagtail integration (called db.sqlite3).
I wanted to migrate to the db_tool.sqlite3 with the following command
python manage.py make migrations
python manage.py migrate --database db_tool
but now I get the following error message regarding wagtail, which I never got before.
django.db.utils.IntegrityError: NOT NULL constraint failed: wagtailcore_page.draft_title
First of all: I don't understand this, because I named the db_tool in particular and I wonder, why the wagtail integration raises an error when I try to migrate to db_tool.
Second: I see no particular field at my wagtail-pages called draft_title and I don't have any draft page at the moment.
Third: the error message also relates to a migration file of wagtail that can be found in the side-packages (see below). So maybe this is the root of the error, but I don't understand the correlation to the other error message, because since now it worked fine and I changed nothing exept of some content of my wagtail pages.
File "C:\Users\pubr\.conda\envs\iqps_web\lib\site-packages\wagtail\core\migrations\0001_squashed_0016_change_page_url_path_to_text_field.py", line 23, in initial_data
root = Page.objects.create(
The wagtail version I use here is wagtail 2.15.2 and I haven't updated it since I started the project...
Due to the fact, that my wagtail-database has the name of the default django-database, could it be possible, that I accidentally tried a migration which was ment for the tool_db.sqlite3 without naming it in the migrate-command and caused this error by doing that?
So I would be very grateful if anyone knows, where the error comes from, or at least, what I could try out to fix it...
Kind regards and thank you!
It isn't clear to me if your database is currently broken or not. Hopefully not, but if it is, please take a back up of each before doing anything else.
This does sound like you might have been trying to operate in the wrong database. Do you have DATABASE_ROUTERS configured? I think that might help you prevent code from one app from getting introduced into the wrong database. The example in the Django docs is mostly focused on read replicas but should be adaptable to your situation: https://docs.djangoproject.com/en/4.1/topics/db/multi-db/#an-example
If your databases are in an incorrect state, start by looking at the django_migrations file in each and then carefully pruning the messed up one until you get back to the separation you have been enforcing.
I am going through the pvlib documentation right now ("A simple ModelChain example") and when I try to import
from pvlib.temperature import TEMPERATURE_MODEL_PARAMETERS I receive the message that the module pvlib.temperature does not exist. Is the documentation not up to date or am I missing something?
Thanks a lot
#chrisomer can you share the link to the documentation you are reading? I don't see the from pvlib.temperature… statement in current docs.
You might be looking at docs for the current master branch on pvlib rather than for latest release v0.6.3. The pvlib.temperature module has been added since v0.6.3 and will be in the next release v0.7.
i am trying django-selectable the 'fruit' example given in the docs here -
https://django-selectable.readthedocs.org/en/version-0.6.2/quick-start.html#defining-a-lookup
getting LookupAlreadyRegistered error,there is a small note on this error,but i can't
figure out how to solve this.i understand that it has something to do with import statements, i am using django-1.3
i will provide more info if needed , but i am just using the same code as given in the example.
kindly help
Check the note in the link you've posted:
You should only register your lookup once. Attempting to register the same lookup class more than once will lead to LookupAlreadyRegistered errors. A common problem related to the LookupAlreadyRegistered error is related to inconsistant import paths in your project. Prior to Django 1.4 the default manage.py allows for importing both with and without the project name (i.e. from myproject.myapp import lookups or from myapp import lookups). This leads to the lookup.py file being imported twice and the registration code executing twice. Thankfully this is no longer the default in Django 1.4. Keeping your import consistant to include the project name (when your app is included inside the project directory) will avoid these errors.
I'm having some difficulty getting my django tests to run properly; I'm using nose, and I started getting an error when the migrations were being applied, that from table 1 a foreign key relation to table 2 failed with the error:
django.db.utils.DatabaseError: relation "table2_column" does not exist
Looking at the way the migrations were being applied it was clear to me that table1 was not created prior to the foreign key relation was applied, so I tried to figure out how to force the dependency, and found the following article:
http://south.aeracode.org/docs/dependencies.html
I then added:
depends_on = (
("app2", "0001_inital"),
)
to my app1/0001_initial.py file.
Unfortunately now I'm getting the following error:
south.exceptions.DependsOnUnknownMigrationMigration 'app1:0001_initial' depends on unknown migration 'app2:0001_inital'.
Any ideas on how to solve this?
I'm not sure if this will solve your problem, but you can add a setting to use syncdb instead of migrations when running tests. Add the following line to your settings.py
SOUTH_TESTS_MIGRATE = False
You have a typo in the name of the migration it's depending on. It should be:
depends_on = (
("app2", "0001_initial"),
)
This dependency system worked for me, after having exactly the same issue you list here, and then finding the dependency system South's docs.
This error is also thrown if there is an error during the import of the target module: If you've got hand-constructed migrations and you're certain the file name matches your depends_on or needed_by, check the referenced file for errors.
Also, setting SOUTH_TESTS_MIGRATE to False won't fix the problem. It just means you won't see the problem until you try to use the migration.
http://south.readthedocs.org/en/latest/settings.html
(That's still useful if you want to speed up your unittests.)
Sometimes when I run manage.py I get a cryptic message in red that says Error: cannot import name <Name> and nothing else.
Obviously, this is a simple import or syntax error and with a little looking around, I can usually fix it. Other times however it takes me quite a while to figure out what exactly I did wrong. Is there a way to get Django to spit out more info in this situation?
This is an annoying problem. Luckily, it's been fixed (recently): see this ticket and this patch.
If you want to just hack your local django install (you're running under virtualenv or buildout, right?), change to the root of your django directory (the one with README, INSTALL, etc) and run this:
curl "https://code.djangoproject.com/changeset/17197?format=diff&new=17197" | patch -p3\
So, if you run django trunk > 17197, apply the patch to your django install (it applied to django 1.2 for me), or wait until django 1.4, you'll be able to do this:
./manage.py shell --traceback
And you'll get a full traceback instead of just the Error: cannot import ...
Voila!
this happens when a circular import appears, when one model is dependent on another and in turn they try and import each other while executing code.
You might want to paste the two models that are causing you issues.
That'll help us debug.
Also it tends to happen sometimes with signals so if you have a signals file please paste too.