Thank goodness for the US Census! The 1999 Census contained public domain info on zip codes (info the businesses usually pay a pretty penny for for the postal service).
I was able to use this data to create a SQL table with some useful zip code info in it like:
City
State
ZipCode class (tells you if it is a unique zip code or po box only)
Lat/Lon (for mapping applications)
I used SQL 2008's great Generate Scripts Wizard to export the table structure, index definitions, and all the data to a single script file. You can find the zip file here (I just know there is a pun in there somewhere).
I will keep an eye out for a newer census report, but zip codes don;t change all that often, so this list should be pretty accurate.
Did this help you? If so, please leave a comment!
David Jedziniak maintains this blog and posts helpful tips and tricks on SQL Server and Dynamics GP development. The opinions expressed here are those of the author and do not represent the views, express or implied, of any past or present employer. The information here is provided without warranty of fitness for any particular purpose.
Monday, January 10, 2011
Friday, January 7, 2011
SRS default parameters
I ran into an issue today where I had a report parameter default that I couldn't seem to get rid of.
In BIDS, I deleted the defaults for all parameters, then deployed the report, choosing the overwrite option.
In BIDS, the defaults were gone when I ran the report. However, when opening from the SRS report viewer window, one of the parameters was still there.
After a bit of troubleshooting and digging around, I found out that the properties that are set up through the SRS report manager in the browser are not always reset when a report is re-deployed. That is what was happening here. Even though all the other changes and even the clearing of the defaults on the other parameters was flowing down when I deployed the report, this one parameter default was remaining in the SRS SQL table somehow.
So I used the report manager to delete this parameter's default too, and we are in business.
I still do not know what caused the issue, so I am adding a step to my personal best-practice for SRS report deployment - open the report manager and review the properties.
Happy Coding!
Did this help you? If so, please leave a comment!
In BIDS, I deleted the defaults for all parameters, then deployed the report, choosing the overwrite option.
In BIDS, the defaults were gone when I ran the report. However, when opening from the SRS report viewer window, one of the parameters was still there.
After a bit of troubleshooting and digging around, I found out that the properties that are set up through the SRS report manager in the browser are not always reset when a report is re-deployed. That is what was happening here. Even though all the other changes and even the clearing of the defaults on the other parameters was flowing down when I deployed the report, this one parameter default was remaining in the SRS SQL table somehow.
So I used the report manager to delete this parameter's default too, and we are in business.
I still do not know what caused the issue, so I am adding a step to my personal best-practice for SRS report deployment - open the report manager and review the properties.
Happy Coding!
Did this help you? If so, please leave a comment!
Subscribe to:
Posts (Atom)
SQL 2022 TSQL snapshot backups!
SQL 2022 now actually supports snapshot backups! More specifically, T-SQL snapshot backups. Of course this is hardware-dependent. Here ...
-
If you are reading this, you are probably aware of the fact that you cannot deploy SSRS 2008 reports on an SSRS2005 server. SSRS reports ar...
-
SQL Job to refresh TEST from PRODUCTION Last Updated: 2018.11.12 I like to include each of these steps as a separate job step. If you ...
-
I ran into an issue today where I had a report parameter default that I couldn't seem to get rid of. In BIDS, I deleted the defaults f...