this might cause you more problems than solve. Can you try out the
following:

--Backing up specific files or filegroups
BACKUP DATABASE { database_name | @database_name_var }
    <file_or_filegroup> [ ,...f ]
TO <backup_device> [ ,...n ]
[ [ MIRROR TO <backup_device> [ ,...n ] ] [ ...next-mirror ] ]
[ WITH
    [ BLOCKSIZE = { blocksize | @blocksize_variable } ]
    [ [ , ] { CHECKSUM | NO_CHECKSUM } ]
    [ [ , ] { STOP_ON_ERROR | CONTINUE_AFTER_ERROR } ]
    [ [ , ] DESCRIPTION = { 'text' | @text_variable } ]
    [ [ , ] DIFFERENTIAL ]
    [ [ , ] EXPIREDATE = { date | @date_var }
   | RETAINDAYS = { days | @days_var } ]
    [ [ , ] PASSWORD = { password | @password_variable } ]
    [ [ , ] { FORMAT | NOFORMAT } ]
    [ [ , ] { INIT | NOINIT } ]
    [ [ , ] { NOSKIP | SKIP } ]
    [ [ , ] MEDIADESCRIPTION = { 'text' | @text_variable } ]
    [ [ , ] MEDIANAME = { media_name | @media_name_variable } ]
    [ [ , ] MEDIAPASSWORD = { mediapassword |
@mediapassword_variable } ]
    [ [ , ] NAME = { backup_set_name | @backup_set_name_var } ]
    [ [ , ] { NOREWIND | REWIND } ]
    [ [ , ] { NOUNLOAD | UNLOAD } ]
    [ [ , ] RESTART ]
    [ [ , ] STATS [ = percentage ] ]
    [ [ , ] COPY_ONLY ]
]

Using triggers, I insert modified table rows to another database for the
purpose of auditing and data versioning. However, I don't attempt to maintain
referential integrity or cascading deletes / updates back to them, becuase
that would defeat the purpose of auditing.
Are you perhaps wanting to partition specific tables, that is move related
data for inactive orders or patients to another database for performance
reasons? Once done, you would like updates or deletes to the base tables to
carry over to the archived partition? Perhaps [distributed partitioned views]
would fit your need. It is basically a view that unionizes two or more
tables, which could span multiple databases or even servers. Rather than
reference the partitioned tables directly, you instead select from and update
the view, and SQL Server's execution plan figures out which table to
reference based on what value is contained in a designated partition column.
It will even transparently implement a delete/insert for a row when you
update it's partition column. This works with v2000+
http://www.fotia.co.uk/fotia/FA.02.Sql2KPartitionedViews.01.aspx#IntroducingPart
itionedViews

Beginning with SQL Server 2005, you can implement [table partitioning]. This
is a similar concept, which is a bit more difficult to implement, because it
involves altering the schema of your tables and enforcing some somewhat
strict rules, but it is easier to manage once setup, because you are dealing
with one physical table. You can still enforce referential constraints like
usual, however, unlike [partitioned views], it cannot span multiple databases
or servers, just multiple file groups.
http://www.mssqltips.com/tip.asp?tip=1200