Brad White writes:
> On Wednesday, December 28, 2022, Brad White wrote:
>> On timestamp fields, I need to update the column default from the current
>> "Now()" to "LOCALTIMESTAMP(0)"
> I'm still suffering here.
I don't understand why a script to generate
ALTER VIEW v ALTER COLUMN c SET
On 1/6/2023 7:44 PM, Ken Tanzer wrote:
On Fri, Jan 6, 2023 at 3:32 PM Brad White wrote:
I can generate ALTER statements, per David's sensible suggestion,
but they fail because you have to drop all the views.
Altering the defaults seems safe because the default value
shouldn'
On Fri, Jan 6, 2023 at 3:32 PM Brad White wrote:
> I can generate ALTER statements, per David's sensible suggestion, but they
> fail because you have to drop all the views.
>
> Altering the defaults seems safe because the default value
> shouldn't affect the view at all.
>
Are you sure those a
On Wednesday, December 28, 2022, Brad White wrote:
> On timestamp fields, I need to update the column default from the current
> "Now()" to "LOCALTIMESTAMP(0)"
>
> I could just manually make the change on every table, but they want the
> existing backups to still work. So I need something that I
On 12/28/22 16:15, Brad White wrote:
RECAP
I'm running an Access front end against the Postgres back end.
Copying and updating a record succeeds in 9.4 but fails in 9.5 and
everything after.
It was the precision of the timestamp fields after all.
Turns out the initial data wasn't coming fro
On Wednesday, December 28, 2022, Brad White wrote:
>
> On timestamp fields, I need to update the column default from the current
> "Now()" to "LOCALTIMESTAMP(0)"
>
> I could just manually make the change on every table, but then we would
> still fail if we ever needed to restore a database. So I
RECAP
I'm running an Access front end against the Postgres back end.
Copying and updating a record succeeds in 9.4 but fails in 9.5 and
everything after.
It was the precision of the timestamp fields after all.
Turns out the initial data wasn't coming from Access, but from the
field default valu
