When adopting a table not part of drupal, and therefore not prefixed, it adapts it, but can't find it when trying to view the content.
The table is called "ext_tbl", but it is looking for "drupal_ext_tbl" (I chose drupal_ as the prefix when installing)

Can that be fixed at all?

Comments

snedled’s picture

A simple workaround:
Apply this patch: http://drupal.org/node/894074
Rename the table to prefix_tablename, then it is adopted all right :)

ClearXS’s picture

Version: 6.x-1.0-alpha13 » 6.x-1.0-alpha14

Fatal error: Call to undefined function data_get_all_tables() in data/data_ui/data_ui.views_default.inc on line 13

Just ticked the module on and processing the request. Yes I have a data table prefix.

Applied this patch: http://drupal.org/node/894074#comment-3379848

Refreshing page returns same error this stage.

delete (rename to .data) module => error disappears on modules page without "data" know=> update.php, admin/content/node-settings/rebuild

(I don't know; is this the proper method of uninstalling when I have to remove the modulein this way, because the site is broken?)

So now putting the (patched) module back => reloading admin/build/modules =>

Only tick-on "Data" & safe config=> no error

Then tick-on Data_Admin_UI , Data_Search & safe config=> no error

Then tick on Data_Node , Data_Taxonomy & safe config=> no error

Finally it remains stable after half a year and several failed trials before. I can't determine if the patch was the solution; I only hope the error doesn't return, for example on a future module update when the patch is automatically overwritten.

ClearXS’s picture

Version: 6.x-1.0-alpha14 » 6.x-1.x-dev
Status: Active » Needs review
x-lette’s picture

I'm also having this issue but patch don't seem to work. I installed data alpha14 and was able to adopt tables within the same database but without drupal's prefix. After that I couldn't do anything with those tables.
Visiting "admin/build/data/compare" it told me that all schemes were missing and a link to 'adjust' those. I tried with one table and all it did was creating a new table (same table name but with prefix. This newly generated table was then presented in other admin corners but of course this table is empty.
I then tried the already mentioned patch but nothing changed. I couldn't see any difference.
Some tables I adopted before applying the patch and some after that. No difference.
Now I'm using current -dev and it still doesn't work.
Can someone please explain how to correctly adopt tables in the same database but without drupal's db-prefix? Renaming the tables isn't an option in my case and all I need is read-only access to those tables. Even views (in the database) are already created and can be used so there is no need to handle joins or foreign keys. This is one thing I'm looking for since I first used drupal!

x-lette’s picture

OK, to push this issue to next step, I renamed all needed tables (i.e. prefixed the names with drupals db_prefix) which in turn forced me to edit all views using those tables to use the new tablenames, but as I thought this could probably lead to some useful results I gave it a try.

These were my steps (hopefully I didn't forget to mention any important step):

  • as described before I installed and upgraded data module to version 6.x-1.x-dev
  • I adopted all needed tables with results as described above
  • in addition to above description I should mention that the list in admin/content/data didn't show any table size and opening any table from there (i.e. clicking on table name) didn't show any content
  • I renamed tables and views and adjusted views without touching data module or its configuration
  • after that the list in admin/content/data now showed the correct number of lines in each adopted table, even in adopted mysql views but opening any table still didn't show any result
  • keep in mind that to this point the tables were adopted without prefix and now are accessible with prefix!
  • now I dropped one table from data module (which in turn drops table from database which is quite a kick in the face of user as there is no other way of deleting an adopted table from the module)
  • I recreated dropped table and tried to re-adopt it in data module but adoption failed silently; table didn't show up in list of adopted tables but did still show up in list of adoptable tables
  • now I went the hard way:
    • I dropped all tables from data module
    • I deactivated all data modules
    • I deinstalled all data modules
    • I recreated all tables with prefixed tablename
    • I reinstalled data module and activated two base modules (data and data admin ui)
    • tried again to adopt prefixed tables but no success at all

In summary I can say that data module doesn't work at all for me. If there is any way to use it successfully with prefixed and/or non-prefixed additional tables in same database I'd really like to know how.

avibrazil@gmail.com’s picture

I'm stuck at the exact same point as #5.

Prefixed or non-prefixed tables won't work.

I can at least configure the table when it doesn't have a prefix, but then, debugging a Views query, I can see it being referenced WITH the prefix. This is wrong.

avibrazil@gmail.com’s picture

The solution for me is to switch to Table Wizard module.

TW is less powerful than the promises of the Data module, but at least it works.

x-lette’s picture

As mentioned in issue #1199430: adopted tables whose name begins with uppercase do not show in "views" I thought this issue might be triggered by using uppercase tablenames but whatever I tried, it failed. Now I'm just fed up with this module and will look for another way to integrate my externally generated data.

joachim’s picture

Version: 6.x-1.x-dev » 7.x-1.x-dev
Status: Needs review » Active

Data module probably needs a policy of never prefixing, but then I'm not sure how we'd get every use of the table to respect that.

Upping version to D7.

joachim’s picture

... or possibly we need to store a flag in our table schema that says whether the table is prefixed or not.

What are the possible cases?

- adopt a non-prefixed table
- adopt a prefixed table
- create a table with prefix
- create a table without prefix

any others? are all the above actual cases that would happen?

giorgio79’s picture

Joachim the cases you propose suffice.