Subject | RE: [firebird-support] Date problem in Firebird |
---|---|
Author | Steffen Heil |
Post date | 2005-06-12T10:18:39Z |
Hi
(which they really shoud be). The values you store may be in dd.mm.yyyy
format, but firebird stores them internally in it's own date format. Your
format is lost at that point.
Then you select those two fields which firebird passes to your client. Your
client app then formats these dates according to your settings and you get
dd.mm.yyyy again. (But not, because you set them this way, but because your
client app restores this format.)
However, the concatenated field of your query needs to be calculated by the
server, since it needs to return a string. Anyway, the server then uses it's
own prefered format and that's not the same as your client app would use.
Hence you end up with differently formated fields.
So, you have two choises.
1. Use some UDF to format the dates for the third field as required. (Bad
idea: Don't transfer redundant information!)
2. Leave out the last field and concat the strings at the client. (Good
idea: No redundancy and also formating according to client rules.)
So, is there a reason to push that last field at all?
Maybe you should tell us, why you think you need to produce this on the
server, and we can help you with your real problem, instead of discussing
simptoms of it...
Regards,
Steffen
[Non-text portions of this message have been removed]
> "select DT_START,DT_END,DT_START || ' - ' || DT_END SHAM fromNo. You said in another post, that these fields are really DATE fields
> year_setup"
>
> iam getting the following result
> dt_satrt=01.04.2005
> dt_end=31.03.2006
> SHAM=2005.04.01 - 2006.03.31
>
> (* Dates are stored in dd.mm.yyyy format in the year_setup table)
(which they really shoud be). The values you store may be in dd.mm.yyyy
format, but firebird stores them internally in it's own date format. Your
format is lost at that point.
Then you select those two fields which firebird passes to your client. Your
client app then formats these dates according to your settings and you get
dd.mm.yyyy again. (But not, because you set them this way, but because your
client app restores this format.)
However, the concatenated field of your query needs to be calculated by the
server, since it needs to return a string. Anyway, the server then uses it's
own prefered format and that's not the same as your client app would use.
Hence you end up with differently formated fields.
So, you have two choises.
1. Use some UDF to format the dates for the third field as required. (Bad
idea: Don't transfer redundant information!)
2. Leave out the last field and concat the strings at the client. (Good
idea: No redundancy and also formating according to client rules.)
So, is there a reason to push that last field at all?
Maybe you should tell us, why you think you need to produce this on the
server, and we can help you with your real problem, instead of discussing
simptoms of it...
Regards,
Steffen
[Non-text portions of this message have been removed]