Unfortunately (for you), I can't write your program for you. I recommend getting a book on C# programming that includes a few chapters on DataSets and XML, and learning from that. The errors your getting tell you exactly what's wrong. The tables you're trying to reference aren't in your DataSet. You need to point to the tables that you want to delete by their names or indices. Somehow or other, and I'll leave it for you to figure out how, you're going to have to inspect the DataSet schema that's created from ReadXml() on your XML listing. Here's a hint: if you're using VS.NET, run your app in the debugger and pay attention to the Autos, Locals, and Command windows. They'll give you a look into the DataSet, and you'll have an idea of what to delete.

Is HDCopy.exe a .NET exe?

sjdevo3gsr wrote:

1. Will calling an unmanaged C++ DLL function (derived from my old app) execute faster than the C# code? I'm thinking about DLL load overhead and similar.

Yes, in this case. Native pointer math is always faster for bitmaps, all other things being equal. If you're doing a lot of memory access and you're sure your not going to overrun any buffers or anything, unmanaged code can be blazingly faster for bitmap work. You may also have easier access to BitBlt and similar functions, which could save you a lot of math.

sjdevo3gsr wrote:

2. Is it possible to embed C++ code directly in the C# project? My books and VS help seem to hint at this, but I have yet to find an explicit answer.

You can put managed C++ classes in your C# project/solution. They're still managed, though. That may not necessarily be bad. You can also but "unsafe" C# code inline in your C# files. That will allow you to use pointers. It's not going to be as fast as native Win32 C code, but it'll allow pointer math, which could save you time over ordinary C# code in this case.

Matt, Basically, you need a collection class in your project that deals with the collections. You can then instantiate as many of them as you like as member variables in your form class. To initialize them, put the instantiation (constructor) in the Form_Load method of your form instead of the Form_Click events.

Even if you can, don't. Where it displays will be indeterminate. The whole point of a service is that you don't need a UI. If you need a UI, you're not writing a service. Your best bet is to write a separate application for getting your messages, and pass messages to your service as necessary. Either that, or you can log to disk.

What's a private assembly? For that matter, what's a public assembly?

Don't bother; it's a waste of time. You're doing an arbitrary query on text in the middle of a bunch of strings. Short of rearranging your data, the only significant optimization you're going to get is by throwing more hardware at it. What does the schema or the rest of the data in the data set look like? Maybe there's some optimization based on the sequences your're looking for vs. the sequences in the data set. It's unlikely, though.

Oh, yeah... this'll work better: int intOld = Int32.Parse(dtOld.ToString("yyyyMMdd")); Removing elements from a DataSet is pretty easy: DataSet dsMyData; // Populate DataSet. ... // Remove a table by name. dsMyData.Tables.Remove("MyTableName"); // Remove a table by index. dsMyData.Tables.RemoveAt(0); DataRow dtMyRow = dsMyData.Tables["MyOtherTable"].Rows[0]; // Remove a row by reference. dsMyData.Tables["MyOtherTable"].Rows.Remove(dtMyRow); // Remove a row by index. dsMyData.Tables["MyOtherTable"].Rows.RemoveAt(0); // Make sure to save changes. dsMyData.AcceptChanges(); dsMyData.WriteXml("c:\myfile.xml"); There are other issues with deleting data from a DataSet, but you may get lucky and avoid the bulk of them. It's worth a try, and ask if you're getting a particular error you can't get through. Stephan

You're on the right track. You've loaded the data and you're iterating suitably. What you need now is to find the date to cut off at, and start removing records. To find the day that was 30 days before today, try this: DateTime dtOld = DateTime.Now.Date.Subtract(new TimeSpan(30, 0, 0, 0)); Unfortunately, and for good reason, there's no easy constructor for TimeSpan to put in the month value and go. You could find it iterativel, something like this: DateTime dtOld = DateTime.Now.Date; while (dtOld.AddMonths(1).Date > DateTime.Now.Date) dtOld = dtOld.Subtract(new TimeSpan(1, 0, 0, 0)); dtOld will contain one month before today when that's running. Next, you need an int value, because the <Date /> value stored in your XML is really just an int. Use this: int intOld = dtOld.ToString("yyyyMMdd"); Now, as you iterate through your set, compare each value to that value. If the int is less than that number, get rid of the data element. HTH, ask more if you need more help.

Just use cast(x as datetime) or the convert function with similar syntax and it'll magically convert to a datetime value. That is, if it's properly formatted, although you seem to believe that it is.

Looks like you and Gulfaraz are working on the same homework problem. How was your spyware signature generated? All you have to do is run the same routine on your file. I'd imagine it's just a byte-by-byte comparison.

What's the error you got? Is this ASP.NET code, or in some WinForm app? You're probably dealing with an authentication error: the user that the code is running as doesn't have login rights to the server.

Sure, try this: declare @list varchar(1000) declare @len int select @list = isnull(@list, '') + colors + ',', @len = len(colors) from ColorTable select @list = substring(@list, 1, len(@list)-1) select substring(@list, 1, len(@list) - @len - 1) + " or " + substring(@list, len(@list) - @len, @len) I'm not in front of a SQL Server right now so I can't try it easily, and I may be off by a character (and thus a -1 or +1 in the substring lengths) here and there. I'm sure you can figure out the tweaks, though. The concept is to have a variable hold the length of the last element. It does this by constantly replacing its value with the length of the current element; at the end of the query, it will contain the length of the last element. Once you know that, it's a matter of string handling to cut your list up and replace text as necessary. Two more things: 1. If there's a possibility that ColorTable may contain zero, one or two rows, or if you're using a where clause that may return only zero, one or two rows, you may want either some if/then or case when clauses with select count statements to ensure you don't return errors. 2. While it's possible to do this in SQL, as demonstrated, there are some things that are better left to code. I assume you have a really good reason for doing it on the SQL Server instead of in whatever language you're using for your queries, but in general I'd recommend this be done in a code library instead of on the DB server.

You should keep your states small. Structs won't work because they don't implement inheritance, but try to keep the information inside your concrete state classes to a minimum. I would avoid the singleton pattern for states. Currently, your states don't really switch. Each tunnels through to the next. There should probably be one top-level controller (it may be a singleton but may not need to be) that decides which state you're in and runs the states: (Please pardon any typos or syntax errors; I'm making this up as I go.) public class MyController { State currentState; public void RunMe() { while (this.currentState != null) this.currentState = this.currentState.RunMe(); } } public abstract class State { public abstract State RunMe(); } public class ConcreteState1() { public RunMe() { // do things. return new ConcreteState2(); } } public class ConcreteState2() { public RunMe() { // do things. return null; } } Likely, you'll want to pass around some objects, and your states will pass out different "next state" objects as RunMe() returns based on what those objects look like. Each state lives only as long as it's executing, so there's no memory overhead. If you're worried about setup/tear-down performance of your state objects (e.g. -- if they have a complicated DB open process and you need them to run really quickly with persistent connections), consider some level of factory for the states: either have a connection factory, give each state its own factory and let it decide when to create a new one of itself, or create a factory class (or implement one in MyController) that decides the lifetime of your state objects. I'd also implement IDisposable and the C# disposal pattern for each of your state objects to clear up unmanaged resources. Managed resources should get cleaned up automatically. The other way to implement this is to have MyController decide which state is next based on the state of some object. My personal belief is that method isn't as good. It's less OO: you might as well just code all the possibilities within the controller and forget the states.

Chris, I'm going to assume that you've set the file type in Folder Options in Explorer to load your application automatically. In the Advanced dialog, you get the command line to run. Using %1 on the command line should give you the FQ path to the file that was double-clicked. Change "c:\program files\myapp\myapp.exe" to "c:\program files\myapp\myapp.exe" %1 Make your Main() into Main(string[] args), and args should contain the path/file that was clicked on. Stephan

What's behind SoundInitState.GetInstance()? Every time I've written something with an Instance property or a GetInstance(), it's been a singleton. If all of your states are singletons, the GC isn't collecting them. Also, what does Stop() do in each of the states? You'd need to be designing something pretty complicated to warrant singleton states. In general, states work better as flyweights. I'd say use structs, but they break the inheritance model.

1. Install hex viewer. 2. Load Access file in hex viewer. 3. Call person on other end of phone line. 4. Read hex codes to other person so they can type them in. 5. Save file on remote end.

You don't want to do that anyway. From a security standpoint, there's practically no value of encrypting passwords on the server if you transmit them over plaintext SQL. Anyone with a packet logger (easy) can get as many passwords as they could by finding an admin password and reading them out of your DB (hard).

That's by far your best option. There's a way to do it with grouping also which may come out faster depending on the DBMS and index structure. Either way, this is a much better solution than using a cursor.

Every DOM object I've ever used has a parse function that will throw an exception or spit out an error if your XML is malformed. Unfortunately, determining well-formedness through exceptions is poor programming form. The only better way I know to do this is with a full parser. As the parser is parsing, it should be able to tell you as soon as it finds a problem without throwing an exception, at which point you know your file failed. A complete run with no exceptions means your XML is good and adheres to any schema you've specified.