[.net] Remoting

::Is this how it is typically done?

Not by anyone having read some documentation in the last 10 years.

Odbc is outdated and dead slow. It is not maintained for a longer time now than the .NET framework exists.

* Use at least OleDb, but better,
* if sybase has them, use the sybase natice connection classes.

::Is this how it is typically done? I'm hoping the DataSet isn't too big to
::throw across the wire. We're just using a TcpChannel and the two machines are
::connected via gigabit Ethernet.

.NET 1.0/1.1: the DataSet is always remoted as XML which is big, bloats, slow and stupid. They overlooked it. You CAN transmit it binary, but then YOU have to make the serialization by hand. For .NET 2.0 they finally clean up this mess - having your data take up 10x as much size on the network than needed is just plain stupid. It is more like the WANT to ALSO e XML, and somehow this turned into the default behavior. I would strongly suggest you google around and fix this in your code.

Beides this we never transmit datasets, but leightweight self-written data containers that our generic DAL turns out upon requests fro mthe server.

Lastly: get rid of the TCP channel. The .NET channels suck big time. Visit http://www.genuinechannels.com/ and get some good ones - the genuine channel suite is simply WAY better than anything .NET delivers. For clarification: these are replacement channels, going into the .NET standard infrastructure.

[Edited by - Washu on January 9, 2005 1:06:02 PM]

I'll try to be polite(r) (Washu please see to this...)

There are several 'native' .NET data providers for Sybase. You can find one of them here. These will be faster than ODBC.

On scalability: a lot depends on the amount of data and the frequency of retrieving it. You should explore caching posibilities. 3 concurrent requests can even be handled by MS Access. I've buid app's that allow 300 concurrent requests without a thought about it.

On speed AND maintainability: consider using stored procedures.

Please post any and more precise questions and we'll help you out.

Cheers

Thanks for the responses. I'm definitely new to this, so I'll take a little bit of 'abuse' if it means I can get good answers.

Quote:

Beides this we never transmit datasets, but leightweight self-written data containers that our generic DAL turns out upon requests fro mthe server.

Exactly my thoughts now - the dataset couples the app server code to the representation inside the database. Nevermind the fact that taking data out from a dataset isn't always pleasant.

On stored procedures: I asked my boss about it during a design meeting but he seemed to reply that they would be too slow for our uses. I don't know either way, so I wasn't going to challenge him on this point in front of others. The '3' concurrent users number comes from the fact that it is a quad-processor machine, with one processor dedicated to doing injection. Not sure how truthful this is, there's a lot in this area I simply don't know (knowing how it works is way different from actual experience). At the moment I'm restricting clients within my Query method through a semaphore, only allowing 3 requests to be processing at any one time. Should the DB server be the one throttling connections?

And I feel like I'm bugging everyone here with these q's; is there a book I can get?

Stored procedures are 'always' faster than queries. An ad-hoc query has to be parsed by the server on syntax and a execution plan has to be made. For a stored procedure this has already been done.

Yes, I would let the DBMS handle the number connections. It easy to configure and has less overhead than a custom throttler.

I'd recommend a class/course so you can shoot your questions at a pro.

Cheers

Awesome, thanks.