I have a simple model in postgresql database and I want to replicate rows of this table in another database in another machine.
The replication should be for some columns of this table and not for all columns.
What is the solution?
If by replication you mean import, look into foreign data wrappers:
http://wiki.postgresql.org/wiki/Foreign_data_wrappers
One of them ought to do the trick.
If you truly mean replication, then… if the other DB is not using Postgres, you could imagine using the above and triggers to keep the changes in sync, assuming of course that Postgres remains the master. If it is using Postgres, there are plenty of additional options to choose from:
http://www.postgresql.org/docs/current/static/high-availability.html
Take a look at the db_link module. You could try something like:
create extension dblink;
then once you have that installed:
select dblink_connect('myconn', 'hostaddr=127.0.0.1 port=5432 dbname=gis user=ubuntu password=ubuntu');
create table some_columns_table as select * from dblink('myconn','select col1, col2 from all_columns_table') AS t(col1 int, col2 text, col3 text);
select dblink_disconnect('myconn);
Related
In CitusDB, I can create an empty table with:
CREATE TABLE table1 (col1 text, col2 text);
I can tell table1 how to partition the data, which will later be loaded into the table, by running this:
SELECT create_distributed_table('table1', 'col1');
In this moment, I will then know how my table is distributed across CitusDB nodes.
However, if I come across a new table that I didn't create, but I know it is distributed, how do I know what column the table is distributed on?
You want to use the citusDB column_to_column function described in the citus db docs: http://docs.citusdata.com/en/v9.3/develop/api_udf.html
SELECT column_to_column_name(logicalrelid, partkey) AS dist_col_name
FROM pg_dist_partition
WHERE logicalrelid='<table>'::regclass;
I have a production database and an archive database in a second SQL Server instance.
When I insert or update (NOT DELETE) data in the production database, I need to insert or update the same data in the archive database.
What is the good way for do that?
Thanks
If they are in the same db instance, a trigger would be trivial assuming it's not a lot of tables.
If the size of this grows, you'll probably want to look into SQL Server replication. Microsoft has spent a lot of time and money to do it right.
If you are considering using triggers for this, then you may want to take into account the load sizes for your production database. If it is very intensive database, consider using some high availability solution such as Replication or Mirroring or Log shipping. Depending on your needs, either of the solution could serve you right.
Also at the same time, you should consider your "cold" recovery solutions which would need to be changed in accordance to what you implement.
Replication will replicate your deletions as well. However, not deleting the deletions from your archive database may cause problems down the line on unique indexes, where a value is valid in the production database but not valid in the archive database because the values already exist there. If your design means that this is not an issue, then a simple trigger in the production table will do this for you:
CREATE TRIGGER TR_MyTable_ToArchive ON MyTable FOR INSERT, UPDATE AS
BEGIN
SET ROW_COUNT OFF
-- First inserts
SET IDENTITY_INSERT ArchiveDB..MyTable ON -- Only if identity column is used
INSERT INTO ArchiveDB..MyTable(MyTableKey, Col1, Col2, Col3, ...)
SELECT MyTableKey, Col1, Col2, Col3, ...
FROM inserted i LEFT JOIN deleted d ON i.MyTableKey = d.MyTableKey
WHERE d.MyTableKey IS NULL
SET IDENTITY_INSERT ArchiveDB..MyTable OFF -- Only if identity column is used
-- then updates
UPDATE t SET Col1 = i.col1, col2 = i.col2, col3 = i.col3, ...
FROM ArchiveDB..MyTable t INNER JOIN inserted i ON t.MyTableKey = i.MyTableKey
INNER JOIN deleted d ON i.MyTableKey = d.MyTableKey
END
This assumes that your archive database resides on the same server as your production database. If this is not the case, you'll need to create a linked server entry, and then replace ArchiveDB..MyTable with ArchiveServer.ArchiveDB..MyTable, where ArchiveServer is the name of the linked server.
If there is a lot of load on your production database already, however, bear in mind that this will double it. To circumvent this, you can add an update flag field in each of your tables, and run a scheduled task at a time when the database load is at a minimum, like 1am. Your trigger would then set the field to I for an insert or U for an update in the production database, and the scheduled task would perform then update or insert in the archive database, depending on the value of this field, and then reset the field to NULL once it has finished.
I have two tables in Filemaker:
tableA (which includes fields idA (e.g. a123), date, price) and
tableB (which includes fields idB (e.g. b123), date, price).
How can I create a new table, tableC, with field id, populated with both idA and idB, (with the other fields being used for calculations on the combined data of both tables)?
The only way is to script it (for repeating uses) or do it 'manually', if this is an ad-hoc process. Details depend on the situation, so please clarify.
Update: Sorry, I actually forgot about the question. I assume the ID fields do not overlap even across tables and you do not need to add the same record more than once, but update it instead. In such a case the simplest script would be like that:
Set Variable[ $self, Get( FileName ) ]
Import Records[ $self, Table A -> Table C, sync on ID, update and add new ]
Import Records[ $self, Table B -> Table C, sync on ID, update and add new ]
The Import Records step is managed via rather elaborate dialog, but the idea is that you import from the same file (you can just type file:<YourFileName> there), the format is FileMaker Pro, and then set the field mapping. Make sure to choose the Update matching records and Add remaining records options and select the ID fields as key files to sync by.
It would be a FileMaker script. It could be run as a script trigger, but then it's not going to be seamless to the user. Your best bet is to create the tables, then just run the script as needed (manually) to build Table C. If you have FileMaker Server, you could schedule this script to be run periodically to keep Table C up-to-date.
Maybe you can use the select into statement.
I'm unsure if you wish to use calculated field from TableA and TableB or if your intension was to only calculate fields from the same table?
If tableA.IdA exists also in tableB.IdA, you could join the two tables and select into.
Else, you run the statement once for each table.
Select into statement
Select tableA.IdA, tableA.field1A, tableA.field2A, tableA.field1A * tableB.field2A
into New_Table from tableA
Edit: missed the part where you mentioned FileMaker.
But maybe you could script this on the db and just drop the table.
How do you export records from one database table and import it into another database table?
(same table structure).
If the table have the exact same structure, and no autogenerated fields you can use:
insert into DestinationTable
select * from SourceTable
You can also use the
select *
into DestinationTable
from SourceTable
syntax, to create and fill the destination table on the fly.
If you also want to keep you identity colums same you can easily do it using code smith template. Download the templates from here and use ScriptTableData.cst template in them. Before that you will required to install code smith on you machine too.
I accidentally coded SELECT $FOO.. and got the error "Invalid pseudocolumn "$FOO".
I can't find any documentation for them. Is it something I should know?
Edit: this is a MS SQL Server specific question.
Pseudocolumns are symbolic aliases for actual columns, that have special properties, for example, $IDENTITY is an alias for the column that has the IDENTITY assigned, $ROWGUID for the column with ROWGUIDCOL assigned. It's used for the internal plumbing scripts.
I don't know why most of the answers are Oracle specific the Question is about SQL Server!
As well as RobsonROX's answer an other example of their use is in the output clause of a merge statement. $action indicates whether the row was inserted or deleted.
A pseudocolumn behaves like a table column, but is not actually stored in the table. You can select from pseudocolumns, but you cannot insert, update, or delete their values.
A simple Google search brings up this from Oracle's reference:
A pseudocolumn behaves like a table
column, but is not actually stored in
the table. You can select from
pseudocolumns, but you cannot insert,
update, or delete their values.
I think that the error you got is simply because there is no column $FOO, so the query parser tests to see if there's a psuedocolumn named $FOO as a fallback. And since there is no pseudocolumn named "$FOO" (and there are no other fallback) you get the error "Invalid pseudocolumn $FOO". This is a guess, though. I'm no expert when it comes to databases.
Pseudocolumns are virtual columns that are available in special cases. In an Oracle database, there's a ROWNUM pseudocolumn that will give you the row number. SQL server, as far as I know, doesn't actually support pseudocolumns but there are errors and stored procedures that refer to pseudo columns, probably for Oracle migration.
One example of a pseudo-column is ROWID in Informix. It is a 32-bit number that can be used to find the data page more quickly than any other way (subject to caveats, such as the table is not fragmented) because it is basically the page address for the data. You can do SELECT * FROM SomeTable and it won't show up; you can do SELECT ROWID, * FROM SomeTable and it will show up in your data. Because it is not actually stored on disk (you won't see the ROWID on the disk with the data, though the ROWID tells you where to look on the disk for the data), it is a pseudo-column. There can be other pseudo-columns associated with tables - they tend to be similarly somewhat esoteric.
They can also be called hidden columns, particularly if they are (contrary to pseudo-columns) actually stored in the database, but are not selected by *; you have to specifically request the column to see it.
pseudo columns are the false columns.
any table will support pseudo columns as same to that of it own column
strictly speaking they are functions:
1.SYSDATE;
2.ROWNUM;
3.ROWID;
4.NEXTVAL;
5.CURRVAL;
6.LEVEL;
Suppose, we have a situation where number of columns are not same in two tables, and we need to apply UNION then generally we take help of Pseudo columns just to perform UNION operation.
Select Col1, Col2, Col3, Col4, Col5 from Table1
UNION
Select Col1, Col2, Col3, Null as Col4, Null as Col5 from Table2