esb
esb
I downloaded the GDA94 files, but the same errors are coming up.
Yep. Both of those things have been done.
Ok, my original hunch was right. The mass of errors is due to a locked transaction from the first failure. I added the "-e" flag to the shp2pgsql command to...
The error file for error_debug_ACT_TOWN_POINT_shp.shp.sql is ``` SET CLIENT_ENCODING TO UTF8; SET STANDARD_CONFORMING_STRINGS TO ON; INSERT INTO "raw_admin_bdys_202108"."aus_town_point" ("town_point","date_creat","date_retir","town_pid",geom) VALUES ('TWP8373','20130731',NULL,'TWN8373','0101000020BB1000005DDB641F27A2624072956B2D33C141C0'); INSERT INTO "raw_admin_bdys_202108"."aus_town_point" ("town_point","date_creat","date_retir","town_pid",geom) VALUES ('TWP8374','20130731',NULL,'TWN8374','0101000020BB100000E707B0F32FA262407145A1E6BD9541C0'); INSERT INTO "raw_admin_bdys_202108"."aus_town_point"...
Yep. That SQL works fine. Here's the dump of the table schema. ``` CREATE TABLE IF NOT EXISTS raw_admin_bdys_202108.aus_town_point ( gid integer NOT NULL DEFAULT nextval('raw_admin_bdys_202108.aus_town_point_gid_seq'::regclass), town_point character varying(15) COLLATE...
I can see the problem.... This file is processed first - ``` shp2pgsql -e -d -I -G -n -i "/vagrant_data/geoscape_202108/AUG21_Admin_Boundaries_ESRIShapefileorDBFfile/TownPoints_AUG13_GDA94_SHP/Town Points/Town Points AUGUST 2013/Standard/TAS_TOWN_POINT_shp.dbf" raw_admin_bdys_202108.aus_town_point ``` Then this file comes...
Yes. The order seems to be wrong. TAS_GCCSA_2011_POLYGON_shp.dbf TAS_GCCSA_2011_POLYGON_shp.shp TAS_GCCSA_2011_shp.dbf TAS_MB_2011_POLYGON_shp.dbf TAS_MB_2011_POLYGON_shp.shp TAS_MB_2011_shp.dbf TAS_SA1_2011_POLYGON_shp.dbf TAS_SA1_2011_POLYGON_shp.shp TAS_SA1_2011_shp.dbf TAS_SA2_2011_POLYGON_shp.dbf TAS_SA2_2011_POLYGON_shp.shp TAS_SA2_2011_shp.dbf TAS_SA3_2011_POLYGON_shp.dbf TAS_SA3_2011_POLYGON_shp.shp TAS_SA3_2011_shp.dbf TAS_SA4_2011_POLYGON_shp.dbf TAS_SA4_2011_POLYGON_shp.shp TAS_SA4_2011_shp.dbf TAS_IARE_2011_POLYGON_shp.dbf TAS_IARE_2011_POLYGON_shp.shp TAS_IARE_2011_shp.dbf TAS_ILOC_2011_POLYGON_shp.dbf TAS_ILOC_2011_POLYGON_shp.shp...
I can confirm that this is an issue as I've encountered it myself. I was unable to get the printing using DieCutLabel template working properly, even though it worked perfectly...
A pretty trivial solution to this scenario is to add a new Intercooler.one function (or equivalent). This simply replicates the current ready function, but creates a separate array of handlers...
Not really. Every call to `Intercooler.ready` pushes the function onto the stack of ready handlers. Pushing multiple calls to `jQuery.one` doesn't really get around the problem.