"
I am working with sumatra having a postgresql database on one of our servers and connecting to it from my work place. Now recently the server's ip changed and I had to change the record store to the new ip adress. Using "smt configure --store newrecordstore" now did now work since when the new_store.sync function was called it exited since the old store is no longer reachable. However in this case there is no sync necessary since the database is still present and only the ip changed. It was easy to overcome this by just out commenting the sync call. However I thought I would post this use case her. Maybe the change_record_store function should get an optional sync = True/False argument?
"
Gregor Wautischer reported on the mailing list:
" I am working with sumatra having a postgresql database on one of our servers and connecting to it from my work place. Now recently the server's ip changed and I had to change the record store to the new ip adress. Using "smt configure --store newrecordstore" now did now work since when the new_store.sync function was called it exited since the old store is no longer reachable. However in this case there is no sync necessary since the database is still present and only the ip changed. It was easy to overcome this by just out commenting the sync call. However I thought I would post this use case her. Maybe the change_record_store function should get an optional sync = True/False argument? "