I would recommend that you create a DTS Package to transfer the object. There was a 'Copy SQL Server Object Task' that was made exactly for this purpose. In this task you specify the source and destination servers, the source and destination databases along with the object(s) you wish to transfer. You will have to specify the exact database object(s) you wish to transfer in the copy tab of this task.
Create the DTS Package and verify that you can execute it in DTS Design Mode. Verify the view was indeed copied to the remote server. You may have to drop the destination object each time the package is executed. Save the package and then you can have the SQL Server Job scheduler automatically kick-start the package by right-clicking on the newly created package and choosing Schedule Package option. From here, you can provide the job scheduling details.
One additional point I'd like to make. I'm confused by your stating that the size of the view can be quite large over time. Views, unlike tables, do not hold data. They are simply named SQL statements we create to perhaps simplify the end-users perception of data in our database. I've also used views for security purposes to hide or exclude sensitive columns. Views, therefore, are not large because they are simply database objects that hold SQL Statements. Granted, the table(s) that view 'hits' can certainly be large.
Here are a couple options you may want look into:
Option 1: Use a linked server
First, you can create a linked server on your source server that points to the target server. Look under the security tab in Enterprise Manager so do this. Once this is done, you can access the target servers' database objects using the fully qualified path name as follows:
TARGETSERVERNAME.databasename.dbo.targettablename
If you choose to go this route, you can create and schedule a SQL Server Job on the source server that has the following Transact-SQL Steps:
Step 1: Drop table TARGETSERVER.databasename.dbo.targettable
Step 2: Select * into TARGETSERVER.databasename.dbo.targettable
From database.dbo.v_vewname
Here, the select into will automatically create the new table every time the job is executed. The schema of this newly created table will match the result set produced by selecting from the view. You can place these Transact-SQL Steps in a stored procedure that resides on the source server if you'd like and have a job automatically execute the procedure on a scheduled basis.
Here's a similar approach that also uses linked servers. The difference is that the second link-server approach assumes that you already have created the target table. This second approach uses a insert / select which is a logged statement while the first uses a 'select into,' which is non-logged. The nonlogged statement should run real fast while the insert /select approach is logged and will be slower.
Step 1: truncate table TARGETSERVER.databasename.dbo.targettable
Step 2: insert TARGETSERVER.databasename.dbo.targettable (column listing)
Select column listing ... from database.dbo.v_viewname
Option 2: Use a DTS package with a data pump
If you don't want to create a linked server definition, you can create a DTS Package that accomplishes the same thing. The DTS Package should have two connections that I will call SOURCESERVER and TARGETSERVER. It is assumed that you will manually create the target table on the target server. The DTS Package then must perform the following steps:
Truncate the targettable on the TARGETSERVER. This step must be done BEFORE the data pump step.
Create a datapump step that specifies the SOURCESSERVER as the source and the TARGETSERVER as the destination.
Configure the Data Pump as follows
The actual source specified in the data pump definition will be the source servers's view
The actual destination specified in the data pump definition should be the target server's target table.
Click on the transformations tab to verify that the source view columns and the destination target table columns map correctly.