SQL database refresh between 2016 SQL (source server/ db) and 2014 SQL ( destination server/ db)

You can't downgrade a MS SQL DB, so neither detach/attach nor backup/restore are applicable.
The Copy Database wizard of SSMS is probably best, but you'll need to have a SQL 2014 instance running and reachable by the 2016 one.

Step A: Downgrade SQL Server 2016 DB to 2014 - Put new DB next to existing on 2014
Step B: Having NEW and OLD DBs on 2014 next to each other upgrade OLD from NEW locally or just replace.
====
Step A (detailed):

Start SSMS
Right click DB and choose "generate scripts"



Click "Advanced"

Set destination version:
Set "Schema and Data":

Set all you need to transfer and click OK


Next > Finish >

You will have the file with SQL Commands - Execute it on SQL Server 2014 and you have it downgraded.

Good luck!

what do you mean put new database next to existing one?  please elaborate

is there a way to refresh data base (taken from 2016 sql database and refresh it on 2014 sql database) on daily bases?

if is, how to create this kind of package?

"refresh on daily base" is something completely different from "migrate". The latter is a one-off action, which might get repeated once in a while. The former requires sophisticated planning to reduce the amount of data to transfer.
Of course you could perform some kind of "snapshot", replacing all of the target database. But that is very inefficient. And usually a sign of design flaw.

To recommend the best approach we need to know the environment and purpose.
Do you need a replication for e.g. development purpose?
Are the DBs used as a "offline" copy for e.g. local caching across company branches?
How large is the data volume? How large the change volume?
Do you need to fully automate?
Are your required to keep changes in the target DBs, e.g. for development settings or anything else differing in the copy?

yes, this is needed for development purposes.  it is required to keep changes in the target DB.  the size of data base is only 18 GB.

There is no way we can provide useful generic advice here above superficial info.

You need to isolate data you changed in the dev DB, then export it (to a different table, DB or file).
Then you either replace the DB, which means to at least truncate all tables and reimport one by one, or have some way to determine new rows (e.g. by a internal date or a flag).
If required, your dev changes exported above need to get reimported or reapplied.

This can be scripted with SSIS.
But you won't be able to reflect meta data change - adding columns, keys, indexes etc. that way. Otherwise you have to recreate all tables etc., and then might get issues reimporting your saved dev changes.

This is a common demand, by the way. But most companies manage it by replacing the whole dev DB each time (monthly or even less frequent), and have dev changes to retain scripted for being able to reapply them.

As others address your question in the literal sense,
What is the issue leafing to this.

You can change the DB to 2014 version while running on SQL 2016.

Properties of DB, change operating mode to 12 from 13 to reflects its change to operating under SQL 2014 rules

You can instal SQL native client library which will allow the connections to .....

I find it easier to solve the issue versus trying to roll back SQL version..

AUTHOR, you asked to elaborate:
1. SQL 2016: You have dbSource
2. Export DATA for update from SQL2016.sourceDB (in Advance settings choose "for version 2014" and "Schema and Data") to the file exported_SQL2016.sql. In the end of Export Wizard save generated job to schedule it later.
3. SQL 2014: Create transportDB (empty DB) next to targetDB
4. Execute exported_SQL2016.sql in SQL2014.transportDB
5. SQL2014: utilizing SQL2014.transportDB update SQL2014.targetDB

Note: It exported_SQL2016.sql contains whole source DB just replace tagetDB with transportDB. But usually developers need data only from prod - they develop new version of the code on SQL 2014 - the code must be preserved after update.

You can schedule 2 SQL Server Agent jobs:
1. SQL2016 Job: (1),(2) from above
2. SQL2014 Job: (3), (4), (5) from above.

To transfer daily:
1. Schedule SQL2016 Job on SQL Server 2016 for 1 am.
2. Schedule SQL2014 Job on SQL Server 2014 for 2 am. (The previous job must be completed by 2 am, or schedule this job for later).

I implemented such approach and it worked many years. We used a table on the source where developers inserted table names that should be transferred. The rest was automated with 2 jobs as described above.