Sep
20
Is your next language COBOL?
September 20, 2008 | Leave a Comment
While I last programmed in COBOL quite a long time ago, I am not as virulently anti-COBOL as some, although I would admit that I would have to be pretty desperate to take another COBOL job!
That said, Dr Dobbs Journal has a pretty interesting article …
Sep
18
SQL Server Replication Ideas
September 18, 2008 | 2 Comments
I have been using Merge Replication for quite a few years now with generally successfull results to keep my order of battle databases in sync with each other.
However, recently, I have been trying to get replication working over FTP between my local database here in Germany and my master database in Canada. This is something that I have had working several times in the past.
Last week, I spent about 5 days trying to get it to work with absolutely no success. I had had a problem with my FTP setup (I use Filezilla) which obviously stopped merge replication from working but I managed to resolve that after a day or so. However, I just could not get replication to work for me.
The difference this time was that my SQL Agent user, which merge replication should use on the client database, was not a domain user but a local user. When I tried to activate the subscription job on the client database, I got an error saying that it could not find the first file on the FTP server to download.
This is a very common error, with many different causes, which I have had before. It can be caused by your firewall now allowing the transfer, the port being closed on the client or server machines, the subscription user account being unable to find the folder or file on the FTP server etc etc.
According to some sources on the internet, it is possible to setup SQL Agent to use the same user account on both the server PC and the client PC as local users with the same password and merge replication across FTP will work, even though the SQL Agent accounts are local and not domain accounts.
Well, I scrapped my replication setup, started again from scratch and got exactly the same error! When I tried with the SQL Agent account explicitly defined, I got a really weird error that only had three entries in Google and all three were talking about SQL Server clusters!! (Which I don’t have).
At that point, I gave up and copied a copy of my client application to the server in Canada and started adding data via Remote Desktop which was a bit slow but worked OK.
Well, I now have a problem with the transaction replication between my master database and my web database on my server in Canada!
Basically, the major problem with replication is that if you want to change a table that is being replicated, you have to remove it from its publication and then put it back into the publication after making the DDL changes to the table or object. You then need to generate a new snapshot to apply to the subscriber.
Well, I have made some changes to my website application and I need to add some new columns to a view. Imagine my surprise when I got an error saying that one of the dbo.sysmerge tables was missing!
According to Google, this can happen when you delete a subscription and recreate it, but I have not been able to find a solution.
Obviously, I could back up my databases and reinstall SQL Server, but as I am not at home that is not something I want to do remotely!
At this point, I have completely disabled Replication completely while I figure out how to set it up again from scratch.
It has got to the point where I am seriously considering writing my own replication solution involving TSQL, MSMQ or Service Broker, FTPÂ and .NET to copy all inserts, updates and deletes from my client db up to my server db and then between databases on my server.
Service Broker is a possibility as I can call it from TSQL, but it is a SQL Server technology and I am considering an “independent” solution that would not tie me so closely to SQL Server.
So, this is why updates have been slow recently!
Â
Sep
18
Siebel 8 Features
September 18, 2008 | Leave a Comment
Well, I have been pretty busy the last few weeks writing integration workflows (or Business Processes) in Siebel 8.0 and I still have a fair way to go before I am anywhere near complete, but this has given me an appreciation of a few features that bedevil Siebel 8.0 which people might be interested to know.
In Siebel 8.0, on the plus side, Oracle have made quite a few changes to Siebel Tools and Workflow in particular so that it is much easier to compare two workflows as the interface now has MDI windows that you can quickly switch between in situations where you are editing two workflows at the same time. This makes it easy to compare workflows or copy steps between two different workflows. This is a big improvement.
On the negative side of the ledger, the Workflow Editor has a slight tendency to change the Business Service of a neighbouring step when you change the Business Service of the step you are editing, so that when you run the workflow, it then complains that the business service and the business service method no longer match and you see that the step in error has the same business service as the one you changed which is correct. This is really annoying!
Another even more annoying feature is that you will make a lot of changes to the workflow in the editor but when you try and save it, Tools pops up a window that says that the record has been changed by another user! You are then stuck, you cannot save your changes, you cannot export the workflow all you can do is cancel your edits and lose your changes. The only possible way of saving your work is to create a new dummy workflow and copy your new steps into that before you cancel your changes.
This one is an absolute killer. So, save your changes frequently if you are doing a lot of editing or writing a new workflow.
Finally, do not try and apply table changes locally, it just uses most of your CPU and hangs. Apply table changes on the server.
Apart from that, I quite like Siebel 8!
