Wednesday, January 27, 2010
Take the iPad for example – there is not a soul that hasn’t heard of it today, it’s unveiling easily eclipsed some “not so important” stories like the State of the Union, the Davos Forum or the Feds meeting to name a few. So, what’s so “magical and revolutionary” about the iPad? Well, it’s thin the “master” said, you can customize the background to your liking and you can turn the thing sideways… really!
So, how can Jobs get away with telling us that we will be able to change the background on this “ground breaking revolutionary” computer? Would he be able to generate this kind of buzz the next time around when he takes the iPad and makes it iPadXL? The reason says no, but, he has proven time and again that he is able to defy reason, he has the magic and can make us drool in anticipation every time!
Monday, January 25, 2010
- Support for Microsoft Report Server 2005/2008;
- Support for Raima RDM Server;
- Support for SVG diagrams. Now the diagrams can be rendered in all browsers, such as Firefox, Opera, Safari, and Internet Explorer;
- Option to use short names in the documentation instead of the three part names;
- Each table and view column is now added to the CHM index;
- SQL Server only: support for an extended property filter. If you use a filter, only extended properties named in the filter will be fetched.
- Microsoft Analysis Server: support for excluding XMLA and MDX code for objects.
- Microsoft SQL Server 2000/2005/2008
- Microsoft Analysis Server 2005/2008
- Microsoft Report Server 2005/2008
- Oracle 9i and above
- DB2 8.2 and above
- MySQL 5.0 and above
- Informix IDS 10.0 and above
- Sybase ASE
- Sybase SQL Anywhere 10.0
- PostgreSQL 8.0 and above
- Microsoft Access 97 and above
- VistaDB 3.0 and above
- ENEA Polyhedra 7.0 and above
- Raima RDM Server 8.1
Friday, January 22, 2010
Here is the scenario: you have tenths, hundreds or maybe more clients using the software you wrote that utilizes SQL Server on the backend. The first release was painless but all the subsequent releases have given you grief - you send out database upgrade scripts with clear instructions but the users just don't seem to be capable of following those instructions and then they call you..., so you are looking for a way to make this process pain free. Well, you are in luck as nowadays there is a tool for everything. Following, I will provide some guidance for each of the scenarios you may be facing.
- If you cannot access the clients' servers from your location (most likely scenario)
- if you have a small number of database versions on the field and each version's schema is "un-touched" - that is you (or the client) did not make any changes to it then the most efficient way to handle this would be to use xSQL Object to compare each previous version to the new "master" version and generate a sync script for each version upgrade and then use Script Executor to package the sync script and any additional scripts you may want to run on the clients' servers into a executable which can then be made part of your installation package;
- if you have many versions out in the field and what's more critical you may have made (or allowed the client to) customizations for different clients then the approach described above would not work very well, but xSQL Builder was designed exactly with this scenario in mind. In just few easy steps you can generate an executable package that embeds the schema of the master database you wish to publish. When the executable is launched on the client's site it will compare the currently installed version with the embedded master schema and synchronize the target to the master. While doing that it will generate a detailed synchronization log and automatically email it back to you so that you know what happened when the client ran the upgrade.
- If you happened to have access to all your clients' databases then you can easily manage this from your location. Use xSQL Object to generate synchronization scripts for upgrading from version x to the current version, then use Script Executor to create a deployment package - basically add all your target servers (databases) into database groups, add your sync scripts into script containers and then map script containers to databases and execute ALL with a click of a button.
- software publishing
- publishing database schema changes
- synchronizing clients' databases (the schemas) to a master database
- comparing and synchronizing database schemas
- executing multiple scripts against multiple databases
Wednesday, January 13, 2010
You can use Script Executor to execute scripts against MySQL 5.0 and 5.1 databases.
You can read more and download your trial copy of Script Executor from: http://www.xsql.com/products/script_executor/
Caller: where is SQL Server 2005 SP3 – I can’t find it?
Support: well, we are not Microsoft but I will help you. Please do a Google search for “SQL Server 2005 SP3”, the first item on the list is what you need.
Caller: but I am using Bing, is that a problem?
Support: no, it is not a problem but the results are not necessarily the same and I am not sure if what you are looking for will be the first item on the list, so, why don’t you do this one search on Google?
Caller: but Bing is my default search and I don’t know how to change it!
Support: how about going to google.com first and then doing the search, you will not need to change anything?
Caller: oh, that is a good idea, a no brainer in fact...
Tuesday, January 12, 2010
- ability to load the trace data directly to the central repository from a UNC path without having to go through the monitored servers temp db;
- the option to set different polling intervals for each trace on each target server;
- the option to configure server level traces reducing the number of traces that will need to be started on the monitored servers
xSQL Profiler allows you to configure and schedule SQL traces to run simultaneously on multiple servers and automatically collects all trace data into a central repository.
You can download the new version from: http://www.xsql.com/download/sql_server_profiler/
Monday, January 11, 2010
From location1, machine1 connects to a remote SQL Server instance, no trouble. Take machine1 move to location2, very similar environment – machine1 fails to connect, the error message is the one above. You verify your SQL Server configuration and everything looks ok, and besides if something was not right you wouldn’t be able to connect from location1 either. So what is the problem?
It turns out location2 firewall is blocking UDP traffic and that is why you are not being able to connect. When the client sends the request to the server asking to connect to server1\instance1 it is the SQL Browser service (on that server) that handles the request and responds with more detailed information to the client, information that the client needs in order to establish the connection to the server. That communication between the SSMS and the SQL Browser service happens over UDP (port 1434). So, when the UDP traffic is filtered out the client does not hear back from the SQL Browser and consequently is not able to establish the connection.
So what can you do if you can’t change the firewall configuration? If you know where your SQL Server is listening then all you need to do is specify the protocol and the port number as shown on the pictures below and you will be able to connect – in this case the SQL Browser service is bypassed since the client already has all the info it needs to connect to that SQL Server instance.