SQL Server - Casi eliminacion en cascada

Hola

Tengo una tabla relacionada 1- N con otra tabla , me gustaria saber como hago que para eliminar un registro de la tabla 1 , me siga quedando el registro en la tabla N pero que me mantenga en la clave foranea el mismo id de la tabla 1.

¿para que?, ¿de que sirve entonces la integridad declarativa de los datos?

si tengo una tabla de prestamos que se le asigna a un cliente dado. Pero quiero
eliminar un cliente en el futuro , pero necesito mantener el prestamo aun , me daria un error de clave foranea al querer eliminar el cliente.

Para hacer eso, necesitas quitar tus CONSTRAINs, pero afectaria para TODOS tus registros, ademas, no veo el caso de borrar los DATOS de un CLIENTE y dejar vivos los detalles del mismo.

Isaias tiene razon , no tiene mucho sentido q quieras eliminar un cliente , si esta relacionado a la tabla prestamos , como sabrias a quien se ledio el prestamo , a menos que tambien guardes el nombre del cliente

despues de todo se me ocurre , que podria crear un cliente
CVarios

le asignas todas las operaciones a este cliente y luego eliminas al cliente
asi no haces cambios en tu bd

seria bueno de que comentaras las razones de pq quieres eliminar un cliente q tiene operaciones

Como solucion, no suena descabellada.

Pero como informacion, al final tendria ENEMIL detalles de un tal "CVarios", que no me diria nada.

La solución que normalemnte implemento en este tipo de casos (donde el historial se requiere) es dar de baja a la entidad (persona, para los casos de rh, cliente, para los casos de admon, etc) y no borrarla.
Es decir, añadir una columna de status al registro (tipo char(1) no nulo) te toma un byte por registro y haces maravillas.
El status te puede informar si un cliente es nuevo, tiene crédito, está en mora, tiene saldo, se dió de baja y un largo etcétera (son 52 status diferentes los que puedes implementar y si extiendes a números y símbolos, las posibilidades se duplican).
Si con el status filtras a los clientes que no están dados de baja, mantienes en buena forma tus reportes y el historial con una buena integridad, además de evitar rehacer registros si lo vuelves a dar de alta.
Entiendo que si no formó parte del diseño original del sistema sería mucho trabajo implementarlo (en captura, edición y reporte), pero vale la pena, por la flexibilidad que le ofreces al sistema.
Esto lo comento por mi propia experiencia, aunque sé que puede haber formas alternas de hacerlo.

Saludos.

¿No seria mejor pasarlo a tablas de HISTORICO?

Comunmente, eso es lo que yo hago.

Saludos

Las tablas de históricos es una de las alternativas, sin duda. Ya sea para los movimientos de una entidad o para la propia entidad o para ambas. Lo que no me gusta mucho de esta alternativa es la implementación de reportes generales, para traer la información 'viva' junto con la información 'histórica'.
Es cierto que pocas veces se requerirá traer la información de lo que ya es historia, pero cuando se requiere junto con la actual, se hacen operaciones más lentas, por ejemplo en el caso de presupuestos definidos por tendencias, factores de crecimiento anual, valores al día (sea de hoy, sea de hace años), depreciación de activos, entre otros. Será que el comando 'union' no es de mis favoritos.
Ahora, reconozco que en cierto momento, he llegado a tener tablas enormes, como ejemplo, la de detalles de documentos, que normalmente hago para que guarde todas las partidas de los ducumentos de cargo o abono (facturas, notas de crédito, remisiones, documentos por pagar, etc), que guardan muchas partidas canceladas, que sin embargo, han probado ser útiles cuando, por ejemplo, un cliente ha cancelado una de las partidas y a los 2 días dice que siempre si quiere comprar, o cuando se deben cancelar y rehacer facturas, para mantener íntegros los documentos fiscales, tanto los declarables como los cancelados, con la información en la base de datos.
Las tablas históricas, en mi caso, las he implementado para llevar control de cambios en situaciones específicas, como aumentos de sueldo, cambios en puntos de re-orden, versiones de planeación, entre otras, para analizar las tendencias y reuso de dichos datos.
Por fortuna, nada es absoluto e incluso puede implementarse de otra manera: Manteniendo los globales (totales, cuentas, promedios, según sea el caso) de las entidades, sea que estén vivas o dadas de baja, en tablas específicas y obteniendo de ahí la información requerida. Esto en casos específicos, como la información fiscal no relevante luego de 5 años o capacidad de almacenaje, luego de comprar/vender o arrendar almacenes, puede llegar a ser más útil y con menos requerimientos de espacio, además de construir reportes más rápidos.
Todo esto, como siempre, depende del análisis de alcance de los sistemas y la definición de la información relevante de la empresa, además de las estratégias de integridad y mantenimiento de la base de datos. Lo reconfortante es encontrar personas con quien debatir a este nivel estas cuestiones.

Saludos.