Non c'è nessuna limitazione (nè by design e nè volendola introdurre artificiosamente) per cui un client a 32 bit non possa connettersi ad un server a 64 bit e viceversa (è anche normale che in SQL Server Configuration Manager vedi vuota quella lista che indichi). Vai a vedere nella sezione "SQL Server Network Configuration" -> "Protocols for nomeistanza" che sia abilitato il protocollo TCPIP e che il firewall del sistema operativo o di altro apparato che fosse presente nella rete e frapposto tra client e server lasci passare il traffico indirizzato a quell'istanza.
Lato client puoi utilizzare il comando TELNET sulla porta utilizzata dall'istanza. Per conoscere la porta puoi vedere tra le entry dell'error log (se stai utilizzando una istanza di default la porta sarà la 1433 a meno che non sia stata modificata), poco dopo l'avvio dell'istanza, dove dovresti trovare una entry simile a "Server is listening on numeroporta". Quando sai la porta usa il comando

TELNET nomeserver numeroporta

e se lo schermo diventa nero significa che la connettività a livello TCP-IP ce l'hai. Se ottieni un messaggio di errore significa che devi trovare a livello di network dove il traffico non passa.
Se la connettività a livello di network non è ostacolata (ed è abilitato il protocollo TCP-IP) ed utilizzi una istanza con nome verifica che sia in esecuzione il servizio SQLBrowser o, in alternativa referenzia l'istanza non nel formato NomeServer\NomeIstanza ma nel formato NomeServer,NumeroPorta

Bye

---

Modificato da l.bianchi il 16 marzo 2011 12.28 -

Il problema non si risolve usando un altro firewall, ma sapendo quale è la porta su cui definire l'eccezione. Se avevi creato la regola sulla porta TCP 1433 è evidente che quell'istanza NON è in ascolto sulla porta 1433 e quale sia la porta lo individui nella maniera che ti ho detto prima. Una volta individuata la porta e creata l'eccezione sulla porta tcp corretta puoi già utilizzare l'istanza referenziandola come NomeServer,porta. Se vuoi referenziare l'istanza come NomeServer\NomeIstanza devi definire anche l'eccezione sulla porta UDP 1434 necessaria ai client per comunicare con il servizio SQLBrowser.
Se stai utilizzando una istanza con nome è anche raccomandabile definire una porta statica per far si che la porta assegnata all'istanza non cambi.
Quanto sopra, ripeto, vale sia se decidi di continuare ad utilizzare il firewall del sistema operativo e sia se decidi di utilizzarne uno di terze parti.

Bye

Luca_spl ha scritto:

Ho un server con 2 schede di rere una con indirizzo ip pubblico e una con indirizzo intranet.

Non è il massimo in termini di sicurezza

Ovviamente devo accedere a sql solo dalla rete intranet.

Puoi definire le schede sulle quali è in ascolto SQL Server tramite SQL Server Configuration Manager nelle proprietà del TCP IP.

Ho creato la regola come programma sqlsvr.exe , e le porte 1433 1434.

Ripeto: è evidente che quella istanza non è in ascolto sulla porta 1433. Se lo fosse (ma stai sicuro che non lo è) diventerebbe superflua la regola sulla 1434 (che dovrebbe essere poi la porta UDP e non TCP)

Ma nn posso tenere una macchina esposta a internet senza protezione.

Io non metterei un database server (server e non istanza) esposto su internet neanche dove la sicurezza è un optional

La maggior parte dei database server sono a 64 bit, la maggior parte dei client sono a 32 bit e questo dovrebbe già convincerti che quella tua fissazione non ha ragione di esistere.
Più verosimilmente è quel tuo codice (bisogna parlare di codice e non di client) che ha qualcosa che non va, ad esempio perchè usa una versione di MDAC (2.6 o precedenti) che non conosce le istanze con nome (ancora una volta non centrano nulla i 32 o 64 bit)