PlausiblyDamp

Re: Web service What do you mean by

Firstly make sure you put Option Strict On at the top of all your vb files - this will prevent a lot of run time errors slipping past the compiler and will highlight where the problem you are having occurs. In regards to parameterising your quesry somethink lile cmd.CommandText = "UPDATE Products SET TotalAmount = ? WHERE ProductName = ?" cmd.Parameters.AddWithValue("TotalAmount", txtboxnew.text) cmd.Parameters.AddWithValue("ProductName", cboxCat.Text) should get you started.

First thing that springs to mind is to check which ports are being allowed out as different instances will be listening on different port numbers.

It would be potentially possible to get it to talk out through a firewall / proxy at your end if SOCKS proxying was enabled but you would probably need to use a tool like SOCKSCAP to enable SSMSE to work with it. Depending on what was then between your connection to the internet and the actual installed copy of SSE you would need further configuration to allow the relevant ports to access the installation. If the database is being hosted by a 3rd party ISP then then chances of this being allowed are virtually zero as it is potential security risk for them, if the DB is being hosted by your own company then you would need to speak to your network admins about gettingthe firewall / proxy configuration modified. It might be helpful if you gave a bit more detail as there may be an alternate solution.

http://blog.gatosoft.com/PermaLink,guid,d0a0dd1e-c9ac-4fa9-a408-615454d49702.aspx might be worth a look, it uses MSBuild tasks to handle such a scenario (and as the article points out deploying to live straight from a development environment isn't a best practice anyway).

In that case you could simply have a app.config with an app setting that points to a network location and read your config from there.

The app.config file is really a VS nicety - the file itself should be .exe.config and be within the same folder as the application itself at runtime. By design the app.config isn't designed to be writeable by users as it needs to be in the same folder as the executable and this shouldn't be writeable by non-admins anyway. User settings should be stored as part of the users profile - if you are writting the config file yourself then either isolated storage or Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData) will put you in the correct place, under VS 2005 if you are using the built-in settings support this will also be taken care of for user settings.

Have you tried using a parameterised query rather than attempting to concatenate the strings?

You could do [highlight=SQL] SELECT TOP 1 FROM Quote, ID Order BY Quote ASC [/highlight]

Nothing obvious jumps out as being a potential cause of the problem.... How large are the images roughly and if they are large what format are they being stored in (jpeg, png etc.) as time-outs are probably the main culprit here.

MSMQ seems overkill if you just want to allow a simple windows app to communicate with a running service, normally you would have the service listen on an IP socket and your windows app would communicate via this.

Could you post the code to the dbConnection.RetrievePhoto method - if anything that is likely to be where the problem lies.

AS there is nothing in the CalculateVAT function that relies on state information held within the class containing it there should be no problems making it a shared function. In fact making it shared better states the use / intent of the function anyway. Just as an aside could you not use something smiilar to Public Shared Function CalculateVAT(ByVal price As Decimal, ByVal vatrate As Decimal) As Decimal Dim d As Decimal = price * (vatrate / 100) d = (Decimal.Truncate(d * 100)) / 100 Return price + d End Function instead and remove the conversion to / from a string when calculating the value?

If the functions in question also manipulate some form of shared storage (global variables, class level shared variables etc.) then these shared resources are not going to be thread safe and therefore will cause problems when used in this manner. Pure shared functions that don't modify any shared state though are perfectly safe to use and as MrPaul points out are used throughout the framework itself without any problems.

I must admit I've never wanted to import a classname other than when I first moved to .Net from VB6 - i find the classname.methodname syntax far clearer to read than just having functions imported into a global namespace. The ability to import partial namespaces and / or classnames can cause problems in the long run as the code you are writing now isn't guaranteed to be non-ambiguous in the future... Currently if I was to import the System.Windows.Forms.MessageBox class I could call the Show method directly (only as an example - again I would find this code very awkward to read at a later date), I could also be doing the same with other classes which do not have a Show method in this version. At a later date when I come to do further maintenance of my code I could now be linking against a different version of one of these other libraries which in this new version include a Show method. This is now going to cause compile time errors and require further (possibly extensive) code modifications (plus testing etc.) to fix. Partial namespaces are also susceptible to the same problem if an existing library adds an additional namespace in a future version. Note that namespaces are a compile time nicety and do not affect the resultant IL code so no existing binaries will be affected - it's just the potential maintenance nightmare that could happen if we ever need to fix / recompile existing code (not that this ever happens much :rolleyes:) I personally just import common namespaces without aliasing them (system, system.data, system.io, system.xml and the like) - it is unlikely a 3rd party will write code that clashes with anything in them plus I use them frequently enough to be familiar with them and their contents. Most other namespaces I tend to import and alias to a few standard abbreviations - this way I keep the advantage of short namespaces (I can't imagine anyone typing System.Runtime.Serialisation.Formatters.BinaryFormatter on a regular basis) but also enforce a uniqueness that should prevent name clashes in the future.

In fact having a rummage around the internet I came across this Project. One of the supporting classes is a timer Clicky that might give you a bit more information. Be aware though both the project and the class in question are licensed under the LGLP and as such you would be bound by it's terms and conditions if you choose to use the source. If you find the license too restrictive or whatever then the basic idea is use the CreateTimerQueue and related functions to generate your events.

Does the event log give any more information? Other than that does the version of the .exe match with the version number in the manifest?

There is still a problem with your code in the fact that Sleep() doesn't have millisecond accuracy either :( You might find the timeSetEvent function more useful as it will take care of raising events based on elapsed time and appears to have the same accuracy as the other WinMM functionality.

Not tried this but you should be able to compile a valid manifest (like the one in the linked article) to a .res file with the rc.exe utility. You would need to generate a .rc file that refers to the manifest. Firstly create a file call .rc #define CREATEPROCESS_MANIFEST_RESOURCE_ID 1 #define RT_MANIFEST 24 CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST ".manifest" Then compile it with the following command line RC.EXE /r /fo .res .rc You can then add the resulting .res file to you VB6 project. Haven't tried it (no VB6 handy) but I've used a similar trick in the past to build custom resource files for VB6 and it has worked fine....

Exactly how high a precision do you need? Are we talking millisecond accuracy being good enough or something more accurate than that? Also be aware that calling .Abort on a thread doesn't guarantee it will exit there and then - plus it throws a ThreadAbortedException you will need to handle as well. Being honest using a high priority thread in a tight loop like you are doing though is not a good way to approach the problem as it will potentially drive the CPU @ 100% and interfere with the performance of other running applications. Would the built in System.Timers.Timer class not be sufficient for your needs?

You would have to put a try catch block within the finally block if you want to supress errors raised there. It might be easier to check for the likely causes (probably the connection object being null / nothing) and simply don't attempt to close the connection if you haven't got a valid connection. Out of interest what language / version of .Net are you using? C# all versions and VB.Net from version 2.0 have a using keyword that pretty much does what you are after.

Not sure why you are getting that error as the Redemption library is a COM library and not a .Net dll - it shouldn't need a strong name (and has no way to get one either). Try removing the reference and deleting the various .dll files from the output folder and then add the reference back again. You never know - it might work :rolleyes:

From the version number it looks like you are running .Net 1.0 on the web server. Make sure .Net is installed on the server and that the virtual directory under IIS is configured to use the correct version.

You could use serialisation do do this, simply point the serialiser to a memorystream rather than a filestream.

If Not EventLog.Exists("Your Log Name") Then EventLog.CreateEventSource("AppName", "Your Log Name") End If Dim log As New EventLog("Your Log Name") log.Source = "AppName" log.WriteEntry("Blah")