Gah! Sorry, I don't know why I assumed you were using Oracle. But the main ideas still hold. If you are updating everything then you could wipe it out and replace it all, but since you are updating only some features then you could use a keyword, which in the case of PostGres is called "Writer_Mode".
The FME Readers and Writers manual may help. What format is the source? Is it PostGres too? Anyway, add the source as a source and the existing DB as the destination. Filter the features as required and use the Writer_Mode keyword to define the correct action. I'm not sure if the keyword is a feature level or a database level parameter. If it's at the database level then I guess you'd have to do at least two runs; one for update and one for delete. Hope this helps. Sorry for leading you off on the wrong track before. Regards, Mark --- In [email protected], Abel Ludba <[EMAIL PROTECTED]> wrote: > > Hello, > We receive updates 2 times a year. What we is to do updating (or modifying) some features. But, we are running our DB on PostgreSQL. Do you mean I can use the Oracle Transformer for PostgreSQL-PostGIS? > Jason said (please see previous message) it could be done by adding PostGIS DB as both source data set and destination data set, and the exposing what I need (source and destination). > I'll try it. > > > > ----- Original Message ---- > From: mark2atsafe <[EMAIL PROTECTED]> > To: [email protected] > Sent: Friday, July 27, 2007 6:26:57 PM > Subject: [fme] Re: Extract and Copy data from a database table > > I think there are two approaches to this problem, depending on whether > you are updating all the data at once or not. > > If you are updating ALL your data, then you can read from the DB, read > the update dxf and the text file. Do a FeatureMerge on the DB source > and the text file to determine what actions to take. If it's unchanged > then write it back to the DB. If it's deleted or updated then write it > to the change table. Then write the DXF to the DB. The key is to make > sure you drop the table before writing. So in other words you read the > table, empty out the table, and write back the updated version. > > If you are only updating part of the data at once, then you'll need to > run it in an update mode that deletes or modifies individual features > in the DB (instead of wiping it all out and replacing it all). To do > that open the Oracle feature type properties, click the Parameters tab > and check out the update key columns setting. You can also use the > Oracle_Delete_ Key_Columns and Oracle_Update_ Key_Columns settings that > are defined in the documentation. I'm not sure how myself, but I can > have someone here post a message if you need help. > > Hope this is useful > > Regards, > > Mark > > Mark Ireland, Senior Product Specialist > Safe Software Inc. Surrey, BC, CANADA > [EMAIL PROTECTED] com http://www.safe. com > Solutions for Spatial Data Translation, Distribution and Access > > --- In [EMAIL PROTECTED] com, Abel Ludba <abel.ludba@ ...> wrote: > > > > Hi everybody. > > > > Thank Jason for answering. > > > > In fact, I'm working with cadastral data. My current database is > PotgreSQL_PostGIS. We receive updates several times per year; I should > integrate them in the DB. We are doing that manually each time we > receive an update. It's really hard: especially managing topological > constraints for our needs (surveyors, architects, managers, etc. are > using our DB). So, I was thinking we should be able to do update > integration with FME. > > > > This is how we do it. > > > > Everything in our DB is polygon or line. Updates are coming to > inform us that one polygon (lets say it is P) was replaced by other > (one or often more than one: p1, p2, ). Each update file contains > descriptive data (.txt file) and geometrical data (.dxf file). I > should deactivate P and send its data to a history_Table. Data of new > polygons (p1,p2, ) must replace previous data of P. So, I'm looking > to extract data of the polygon P and replacing them with those of p1, > p2,.. I must do the same process for each line of P and p1, p2,... > > That's what I'm trying to do. I hope it's clear. Please, if not tell > me and I'll send you more details. > > > > It's easy to do with Java, or other programming language. But, FME > should also do that : very challenging and interesting. > > > > > > Thanks. > > > > Abel. > > > > > > > > > > ----- Original Message ---- > > From: Jason Birch <jason.birch@ ...> > > To: [EMAIL PROTECTED] com > > Sent: Thursday, July 26, 2007 6:43:32 PM > > Subject: RE: [fme] Extract and Copy data from a database table > > > > It should be. Are you sure you don't want to do this with straight SQL > > instead? It's easier... > > > > It's not too hard in FME though. Basically, you add the PostGIS > > database as both source data set and destination data set, exposing the > > appropriate source and destination tables as feature types. > > > > Then you use some kind of filter (depending on what rows you want to > > copy to the other table) by adding an appropriate transformer in the > > workspace or in the select/where parameters of the source table's > > feature type. > > > > If I understood you incorrectly, and you want to transfer all of the > > rows, then it's as easy as adding the source and destination feature > > types and connecting a line between them, and possibly remapping the > > column names. > > > > Perhaps explain your problem in more detail if this doesn't make sense? > > > > Jason > > > > -----Original Message----- > > From: abel.ludba > > Subject: [fme] Extract and Copy data from a database table > > > > Hello > > > > I'm working with PostgreSQL- PostGIS database. I'd like to extract data > > (some lines) from a table and copy it into other table. > > > > Is it possible to do that with FME? If yes, can you please tell me how? > > Thanks. > > > > Abel. > > > > For insights into what's up at Safe Software and what's on the > > development horizon, visit Safe's blog at spatial-etl. blogspot. com. > > > > Love FME? Then open your diary to March 6-7, 2008 and write this... > > "Second Worldwide FME User Conference - Must Attend!" See > > http://www.safe. com/company/ fmeuc2008/ index.php for more details. > > Yahoo! Groups Links > > > > > > > > > > > > Be smarter than spam. See how smart SpamGuard is at giving > junk email the boot with the All-new Yahoo! Mail at > http://mrd.mail. yahoo.com/ try_beta? .intl=ca > > > > > > > > Be smarter than spam. See how smart SpamGuard is at giving junk email the boot with the All-new Yahoo! Mail at http://mrd.mail.yahoo.com/try_beta?.intl=ca > For insights into what's up at Safe Software and what's on the development horizon, visit Safe's blog at spatial-etl.blogspot.com. Love FME? Then open your diary to March 6-7, 2008 and write this... "Second Worldwide FME User Conference - Must Attend!" See http://www.safe.com/company/fmeuc2008/index.php for more details. Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/fme/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/fme/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
