I have PostgreSQL installed in several customers (always in Windows).
I'm facing some situation with current_timestamp, wich depending of "Windows Auto Adjust DST", is returning "wrong" time, even if I set the same timezone used by windows (in this case 'BRAZIL/EAST').
The problem is: I can tell to the users to set (or unset) Auto DST. So, is there any way to workaround this? I mean, some kind of setting on PG that will allways get the exactly same time shown on taskbar clock?
Thanks in advance.
Does it display a good time if you use the following?
select current_timestamp at time zone 'BRAZIL/EAST' as now;
Maybe your Windows clients or server have timezone set wrong or outdated timezone data. Is your server supported (at least Windows 2003 SP2) and updated with WindowsUpdate? Is your client at least Windows XP SP3 and WindowsUpdated too.
What the following query returns when connected locally from server and from remote client?
SELECT current_setting('TIMEZONE');
Christian,
i've faced the same problem.
try setting this in postgresql.conf:
timezone = 'BRAZIL/EAST'
hope that helps! ;)
Related
I have a problem that i have a difficult time explaining, which makes any online search very hard. Here is my dilema.
I'm migrating a VM. The purpose of this machine is to compile send out daily/weekly/monthly reports. I know there are other ways (like Power BI) but this is the situation we are in right now. The older machine has win10 pro and office 365 installed while the new has win10 enterprise version and office 2016 installed. This machine runs 24/7 in the background running specific tasks (via system scheduler app) at given times, that is it's a Virtual machine and has done so without issues since it was created. The reason for the migration is because we need to domain change and bring the machine under a new corporate policy and we don't want to do this on a live server.
We've set it the VM's the same way, same programs and same settings. Everything seams to be running smooth expect for this one thing, and here is the problem i have a hard time to explain or figure out:
MS Access will update the tables and the computer will run the tasks as set but it will not export the data to pdf unless i have a remote desktop connection open. Will not export the pdf's otherwise. MS Access uses a autoexec macro where the pdf export is set with ExportWithFormatting. This works without issues on the old server.
We thought this to be a permission or user specific issue at first but even re-creating the tasks did not work and changing paths. Otherwise also i expect we would have problems with tables updating, specially since it works when you have an active remote desktop conn running.
I'm lost and therefore hoping this community will be able to help or guide me to a solution.
I believe that we found the reason for this. It was caused by windows easy print and the printer drivers of the machine. It worked for some reason differently between the servers. after reinstalling the printer drivers and a few restarts it started working. It exports now from access again.
This is at least solved.
I am using WUA (Windows Update Agent API) to check for the installed updates on my computer.
What I found interesting is the Date property value (http://msdn.microsoft.com/en-us/library/windows/desktop/aa386400(v=vs.85).aspx) is hugely different from the real installation time, i.e local time. For example, for one patch "Security Update for Microsoft .NET Framework 3.5.1 on Windows 7 and Windows Server 2008 R2 SP1 for x64-based Systems (KB2789645) ", using WUA API, I see the Date value = '2/21/2013 11:04:30 PM', while on my computer, I found in the EventLog, it is logged as "2/21/2013 4:51:58 PM". I initially thought the WUA API is using UTC time, but if I change the UTC time to local time (I am at Pacific time zone), then '2/21/2013 11:04:30 PM' (UTC) will be equal to '2/21/2013 3:04:30 PM' (local), still far away from the eventlog's "2/21/2013 4:51:58 PM".
Does anyone know what this Date property of IUpdateHistoryEntry really means? According to MS in the above msdn link, the Date property is
Property AccessType Description
Date Read-only Gets the date and the time an update was applied.
Thanks in advance for your help. I am puzzled by this difference.
Kind regards,
JYao
For some strange reason the Borland StarTeam Toolbar utility does not save its data (and thus does not cache/memorize the last used ST servers and is essentially completely useless). I thus have to log in manually each and every time I access ST, which is a nightmare.
Our IT folks have no idea, why on my system it does not save the data as it's supposed to. They claim, it's the first and only system showing this anomaly...
Any idea, where this toolbar saves the data to? Does it need some environment variable set to do this properly or something similar? Any pointer would be highly appreciated.
I am using this on a Windows 7 (x64 Ultimate) system, ST is v2009 (build 11.0.0-68), ST Toolbar is v11.0.0.38.
You are running quite a mid-range build of the 2009 StarTeam Client. I would recommend upgrading to the latest 2009 client,
http://supportline.microfocus.com/websync/STarTeam2009E.aspx
Current latest build is 11.0.0.91 and Windows 7 was only strictly listed as supported for builds 11.0.0.72 onwards.
Maybe the source of your issue.
Thanks.
It seems to store some options under HKEY_CURRENT_USER\Software\Borland\StarTeam Toolbar. But the login information appears to be stored somewhere else.
It's a dumb question, but are you sure that "Save as default credentials for this server" is checked when you login?
In Windows CE 5.0, after changing some registry values, the changes don't take effect and I must restart Windows.
How can this be done without restarting Windows?
I was tasked to do this early this week for CE4 so I thought I'd share my findings here (whether or not it's still needed) -- after I updated the registry, I ran this "SaveRegistry.exe" tool from the manufacturer's SDK; see these links for a start and look through your manufacturer's files/setup/install CDs as you may find SDK or sample code:
http://www.microlise.net/VRC8900net/secondary_html/os_version.htm
and
http://www.garz-fricke.de/download.php?fid=380&lg=en
This tool was done in C++ but you can call the executable from whatever language you used.
If type of your registry is hive, you may call RegFlushKey API function.
The LAN which has about a half dozen windows xp professional pcs and one windows 7 professional pc.
A jet/access '97 database file is acting as the database.
The method of acccess is via dao (DAO350.dll) and the front end app is written in vb6.
When an instance is created it immediately opens a global database object which it keeps open for the duration of its lifetime.
The windows 7 machine was acting as the fileserver for the last few months without any glitches.
Within the last week what's happened is that instances of the app will work for a while (say 30 mins) on the xp machines and then will fail on database operations, reporting connection errors (eg disk or network error or unable to find such and such a table.
Instances on the windows 7 machine work normally.
Moving the database file to one of the xp machines has the effect that the app works fine on ALL the xp machines but the error occurs on the windows 7 machine instead.
Just before the problem became apparent a newer version of the app was installed.
Uninstalling and installing the previous version did not solve the problem.
No other network changes that I know of were made although I am not entirely sure about this as the hardware guy did apparently visit about the same time the problems arose, perhaps even to do something concerning online backing up of data. (There is data storage on more than one computer) Apparently he did not go near the win 7 machine.
Finally I know not very much about networks so please forgive me if the information I provide here is superfluous or deficient.
I have tried turning off antivirus on the win 7 machine, restarting etc but nothing seems to work.
It is planned to move our database from jet to sql server express in the future.
I need some suggestions as to the possible causes of this so that I can investigate it further. Any suggestions would be gretly appreciated
UPDATE 08/02/2011
The issue has been resolved by the hardware guy who visited the client today. The problem was that on this particular LAN the IP addresses were allocated dynamically except for the Win 7 machine which had a static IP address.
The static address happened to lie within the range from which the dynamic addresses were being selected. This wasn't a problem until last week when a dynamic address was generated that matched the static one and gave rise to the problems I described above.
Thanks to everyone for their input and thanks for not closing the question.
Having smart knowledgeable people to call on is a great help when you're under pressure from an unhappy customer and the gaps in your own knowledge mean that you can't confidently state that your software is definitely not to blame.
I'd try:
Validate that same DAO and ODBC-drivers is used on both xp- and vista machines.
Is LAN single broadcast domain? If not, rewire. (If routers required make
sure WINS is working)
Upgrade to ms-sql. It could be just a day of well worth work, ;-)
regards,
//t