Thanks. I would have never guessed in a million years. Darien "I don't know. I haven't tried today." - Trumpet icon Maynard Ferguson's response when asked how high he could play.

Thanks for the reference. Darien "I don't know. I haven't tried today." - Trumpet icon Maynard Ferguson's response when asked how high he could play.

Here's the query... I have an object that implements ICollection and want to expose it via a webservice. From everything I've read, the easiest approach is to dump the relevant data into an XML friendly object (i.e. DataSet, DataTable) and return (voila!). The question being more about style than substance, since I am not ever going to be returning more than a single datatable from a collection object, should I simply transform the data into a DataTable than a DataSet? The main benefits I've experienced from using DataSets come from managing multiple DataTables and their relating data... neither of which apply here. Am I on target or missing something? :cool: Darien "I don't know. I haven't tried today." - Trumpet icon Maynard Ferguson's response when asked how high he could play.

I have the following situation: Person A performs an application action that affects Person B. Management wants the application to automatically generate an e-mail to Person B, notifying them of the action. I can think of two solutions. 1) Query the Active Directory LDAP server for the e-mail address tied to Person B. 2) Get a dump of the e-mail addresses from the Exchange administrator and tie it into the application like another table. I don't like #2 because it doesn't account for change very well and I don't want to implement ANOTHER import/reconcile process if I don't have to. However, I've never done LDAP work and don't know how to exactly go about "eating this elephant". The proverbial answer is "one bite at a time", but where to start? :confused: BTW: The application is ASP. NET. The domain is Win Server 2000, Exchange 2000, and SQL Server 2000. Suggestions, pointers, hints, and help are welcome. Thanks in advance, Darien "I don't know. I haven't tried today." - Trumpet icon Maynard Ferguson's response when asked how high he could play.

TTIWWOP? That's one that I haven't heard before. :confused: Darien "I don't know. I haven't tried today." - Trumpet icon Maynard Ferguson's response when asked how high he could play.

Ahhh... but watch out for those Puerto Ricans ;P Darien "I don't know. I haven't tried today." - Trumpet icon Maynard Ferguson's response when asked how high he could play.

Speaking strictly from a normalization perspective, since any given user can only have one city or state, I would probably have a CityId and a CountryId element in the users table. I would make the countryId NOTNULLABLE and the cityId NULLABLE. I would then have those two id columns referenced to two lookup tables ( tblCountryLkp, tblCityLkp ? ) that would contain valid entries for their specific entities. A stored procedure could then be used to reference another table ( tblValidCountryCities ? ) that would contain all valid combinations of cities and countries. Any insertion would be validated against this table and a non-conforming combination would result in an error. Hope this helps, Darien "I don't know. I haven't tried today." - Trumpet icon Maynard Ferguson's response when asked how high he could play.

Well.... I was brainstorming and trying to think about different ways you could ensure the integrity of the data. i.e. Allowing London, U.K. and disallowing Los Angeles, Nigeria... Darien "I don't know. I haven't tried today." - Trumpet icon Maynard Ferguson's response when asked how high he could play.

Does the database platform you are using support stored procedures? Darien C#, VB.NET, Oracle, Sq(uirre)l Server "I don't know. I haven't tried today." - Trumpet icon Maynard Ferguson's response when asked how high he could play.

First and foremost, I suppose that "SProcedure" is short for "stored procedure", since I know no object in the .NET framework with that name. The other three have their different purposes. SqlReader: Lightweight, very fast. Read-Only, forward-read, server-side cursor. Good for populating lists or retrieving other data that you do not need to keep readily available for transactions. SqlCommand: Pretty much a necessity if you are going to issue a transaction to a database. The only question is whether you are going to do it in a stored procedure or a text string. If the RDBMS you are using supports stored procedures, I would unconditionally support that. Not only do you wrap your insert values in parameter objects ( prevents SQL injection hacks - another column entirely ), but the stored procedure is already pre-compiled and should execute faster than a SQL-text insert. SqlDataAdapter: Used to fill datasets / datatables with data resulting from a query. Very powerful, as you can use this object to populate relational data from your database and use the dataset object to maintain the information in memory. You just have to be very careful about how you construct your transaction logic, as it can become a major headache. Also, check the layout of your database's table structure. Make sure that each table has ( at least ) one index defined and that you are utilizing it as often as possible when retrieving and updating table information. Finally, check your querys and check any joins that you may have. Full table joins ( joins without indexes ) and < gasp > Cartesian joins can stall even the best server if the tables are large enough. Hope this helps, Darien :beer: "I don't know. I haven't tried today." - Trumpet icon Maynard Ferguson's response when asked how high he could play.

There's got to be something wrong with what I'm doing. The database responds fine with the following code: :) ** Bracketed code is edited to protect the innocent **

Imports System Imports System.Data.OracleClient Public Class Driver Public Shared Sub Main() Dim conn as New OracleConnection conn.ConnectionString = "Data Source=[DBName]; User Id=[User Id]; Password=[Password]" Dim cmd as New OracleCommand cmd.CommandText = "SELECT * FROM USERS WHERE USER_ID = '[USER_ID]'" cmd.Connection = conn cmd.CommandType = CommandType.Text Try Dim odr as OracleReader odr = cmd.ExecuteReader() Catch ex As Exception Console.Writeline( ex.Message ) End End Sub End Class

Now, upon replacing :

cmd.CommandText = "SELECT * FROM USERS WHERE USER_ID = '[USER_ID]'"

with a parameterized query like :

cmd.CommandText = "SELECT * FROM USERS WHERE USER_ID = :pUserId" cmd.Parameters.Add( new OracleParameter( ":pUserId", OracleType.VarChar )).Value = "[USER_ID]" )

results in the return of a ORA-12571 : TNS:Packet Writer Failure :( I've tried most everything I can think of and I can't around this. :confused: The environment is Windows 2000 Server, Oracle 9i, and VS 2003. Thanks in advance, Darien "I don't know. I haven't tried today." - Trumpet icon Maynard Ferguson's response when asked how high he could play.

RChin wrote: You need to spend more time in CP. (and don't tell me you don't know what CP is!) ai carumba! You don't know Bob ( :bob: ) and the dancing man ( :jig: ) Please forgive me. :sigh: I'm stil l quite a newbie when it comes to CP (yes, I do know that that is) culture... and I wasn't going to miss out on the inside jokes forever. ;P You'll never know if you don't ask. It's neat to see that the little green guy has a name. :laugh: Darien C#, VB.NET, Oracle, Sq(uirre)l Server "I don't know. I haven't tried today." - Trumpet icon Maynard Ferguson's response when asked how high he could play.

Wow! The first five days of this month have already passed. :omg: Happy Cinco de Mayo!! :beer: BTW: Mike, how did you get that dancing figure on your message? .... and who's Bob? Darien C#, VB.NET, Oracle, Sq(uirre)l Server "I don't know. I haven't tried today." - Trumpet icon Maynard Ferguson's response when asked how high he could play.

Bravo! Good form. Take a bow. :-D

I left VB 6 a while ago ... :-D but I'd consider returning to the old ways for the right price. Woo Hoo! :-D My first CP post :):-D:cool: Darien "I don't know, I haven't tried today." - Trumpet icon Maynard Ferguson, when asked how high he could play.