I have a working Drupal site that i need to replicate on another server, so that the replicated version doesn't contain custom site information like users data or specific article published on the main site.
So i did a selective dump of the main db, and re-imported in the replicated site. In the specific case of the "node" table, I imported only nodes of the type "page". Now, all went well. The main functions of the site are working, but i have a problem with pages throwing an error "The requested page "/node/page_number" could not be found." with ALL the basic node pages. I can see only views and the front page.
Probably i'm not dumping some information needed by Drupal to display the node. So the question is: where i can find info about basic nodes? I thought porting the table "node" and "node_access" was pretty enough, but really it isn't.
The problem is that node table stores only basic information.
I think you did not imported node_revision table as well.
Even if you do, dumping tables and re-importing only specific data into another database breaks their connections, by resetting id columns and missing extra data provided by fields and other custom modules.
Consider using Import/Export modules, comparison of which you can find Comparison of Content and User Import and Export Modules
Consider the data_export_import module.
What I like about data_export_import is that it is an all-in-one module (for export AND import of data. Whereas as with some other solutions, the import and export stages are done by separate modules, which could mean that extra work is needed ensuring compatibility of the export with the import.)
Related
Using t-code SEGW, I created a SAP Gateway project with several data models based on RFC function modules. The data structure is based on the handy "Import" funtionality.
Due to a customer request, I had to copy the project into another, customer owned, namespace.
After the copy, I lost the funtionality to import fields to the data models.
When I create a new entity, the possibility to import is still there. When I copy a fully working project, lets say to $tmp, I lose the import feature again.
Sure, I can still edit my entities by hand but it is tiresome and prone to errors.
So, my question, is there a way to re-enable the import feature of copied SAP Gateway projects?
Check if you are importing complete project into customer system, check for the service and model. It should have come if the project has been imported successfully.
Note: Please update SEGW with latest release.
This is my first time using filemaker and I'm in the process of converting a client's filemaker project to a webapp. Currently, I am trying to export the current data so that I can put it in a database.
I've found that tables don't appear for export unless they appear in the "Relationships" graph, and I've found that I can export the data using the "Export Records" script command.
This all works fine except that I can't seem to export all the records. In the database manager, one of the tables reports that it has 596 records, but when I export it I only get 119 records. The same is true for all other tables I've tried, they report more than 119 records, but the exported data only has 119.
Any ideas or help is welcome
edit
More progress, it seems the script runs in the context of the current layout, so the number of records is related to the number of results in the current layout. Is there a way to automate creating layouts for tables that don't have them so that I can export all the data for each table?
The concept you were missing was the "found set". FileMaker exports the currently found records in the current layout. You can create a script that grabs the names of the layouts within the file, sticks into a variable, goes to each layout in turn, performs a Show All Records, and then runs an open ended export. However, I'm wondering how many base tables there actually are?
As to creating layouts - nope, there's no programmatic way. However, it is possible to use an external key macro type app (QuicKeys?) to run through the create layout dialog and choose a new table each time.
I have implemented several custom modules which essentially bridge Drupal with some third party applications we build in house.
Now as my knowledge of Drupal grows I am curious to know whether or not it is possible to integrate my modules with Drupal VIEWS for reporting purposes.
My modules connect directly to several MySQL databases on an external server and perform queries and render those results within the context of Drupal.
What I would like to do, is use VIEWS somehow to SELECT and manipulate the query as a Drupal VIEW to avoid having to re-purpose the module queries each time a change is requested.
Basically, is it possible to expose the SQL tables in an external app to one which Drupal VIEWS can pick up? I have googled and found a few suggestions but no one seems to know for sure???
It seems drupal expects all content to be of it's own internal "content type" and thus connected to it's core "node" - is this an assumption VIEWS makes?
I don't want to export my third party data into Drupal "nodes, content types, etc" simply so VIEWS can effectively read and render the results.
Seems to me, this should be possible with a Drupal module bridging the gap somehow???
Cheers,
Alex
You could use data module http://drupal.org/project/data
It gives you option to use views on your custom tables. I hope this helps you.
I'm importing some customer information from Landslide CRM into Salesforce.
Anyone have advice on the best methodology for doing the import?
It seems like the Apex Data Loader is the best way to go, but I don't know
if there are any issues with handling the objects in question, or if there
might be a specific tool or script to perform this migration.
Any experience with this import in specific or importing data into Salesforce
in general would be appriciated.
Importing Data to salesforce can be achieved in multiple ways depending on the type of data nd the requirements you have.
The first thing to do is get your data into CSV files so you'll need to find a way to export the dat afirst. For UTF-8 encoded data don't use Excel use something like OpenOffice (only required if you have UTF-8 Characters)
If its account and contact data for example. There is an import wizard available in Setup > Administration Setup > Import Business Accounts/Contacts
Next Option is as you say to use the Apex Data Loader. This probably the best approach.
The first thing and this is critical for big migrations is to Create a Field on your account object which will be a Unique Field for reference purposes. When creating this field set it as an External ID field and populate it with a unique reference for your accounts, the same goes for anything else which will be a parent. (you'll see why shortly.)
Next use the Insert option in the Data Loader to load the data mapping all the fields, especially the External Id
Now when you upload child objects use the Upsert option and map your Account Id via the External Id created earlier. This will match the accounts using your unique Id instead of you having to use the Salesforce id, saves alot of time.
Repeat the same for other objects and you should be good to go.
Apologies for the lack for structure here... doing this while in work and don't have alot of time but hope this helps.
The data loader works great for most types of imports. The one suggestion I would give you is to create a new custom field on your target objects (presumably Account and Contact) called "Landslide ID" or similar, identify it as an external ID field, and then import the primary keys from your source system into this field (along with the "real" data).
Doing this achieves a couple things - first, you have an easy unique link back to the source data for troubleshooting or tracing back to the source system. Second, if you find yourself in a situation where you need to import more fields or related data from the original source system, you'll be able to do so in an easy and correct way. It's just a good standard practice to adopt when doing data migrations -- it's almost no additional effort and can save you many hours in the future.
I am working on a Drupal site with a few friends. Obviously we can Version control the code... but what do we do to keep each others databases in check?
I have managed to get all the theming into files (contemplate etc), but ideally my views settings, menu settings would be in line also... (Not worried about Content either way as we're just building the framework)
Any suggestions?
Using Features along with Context is very powerful. Context lets you create a "section" for your site. It's best illustrated through an example:
Lets say we define the "Forum" context as anything with the url of forums/*. Context lets us say: "I want to show these three views in the right side bar, only when I am in the "Forums" context.
Now, using Features, we can create "module" define by the context. So, we will end up with a module called "youSite_forums", which will include all the views, blocks, etc. that was define in your Forums context. It also will determine the correct dependencies, as well as Content Types used in the context. All will be bundled up nicely in a module.
As for versioning content such as node, you can user either Node Export, or just do a DB dump using Backup and Migrate. We use these occasionally, but we never have every node versioned in SVN.
Links:
Features
Context
Backup and Migrate
Problem Solutions in Database Migration from Development to Live Sites
You can find some more opinions on this here: Drupal DATABASE deployment strategies?