[fdo-internals] RE: ArcSDE Provider issues
Chris Erickson
chris at cartopac.com
Fri Mar 6 16:53:23 EST 2009
I don't see an applicable limit there...
Here is the current output I'm getting (from our program, but all the same):
<Entry>
<Attribute Name="OBJECTID">1</Attribute>
<Attribute Name="Text">TEst1 -- modified</Attribute>
<Attribute Name="NonUnicodeText" />
<Attribute Name="StringN4000">TEst1 -- modified</Attribute>
<Attribute Name="String4000">TEst1 -- modified</Attribute>
<Attribute Name="StringNMax"></Attribute>
<Attribute Name="StringMax"></Attribute>
</Entry>
There are only 2 places I see that need it changed. In ArcSDEFeatureCommand::GetValueFromStream and ArcSDEFeatureCommand::assignValue.
GetValueFromStream isn't used that I can find, and I've been working on updateing assignValue.
>From the above, I still see the following issues:
Non-Unicode CLOBs don't work.
Varchar(max) strings don't work.
chris erickson
developer
chris at cartopac.com
970.493.9500 x 191
970.482.1485 (fax)
-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Romica Dascalescu
Sent: Friday, March 06, 2009 2:45 PM
To: FDO Internals Mail List
Subject: [fdo-internals] RE: ArcSDE Provider issues
Strange.. Shouldn't they use following limits?
#define SE_MAX_PROP_NAME_LEN 32 /* MAXIMUM PROPERTY NAME LENGTH */
#define SE_MAX_PROP_VAL_LEN 512 /* MAXIMUM PROPERTY VALUE LENGTH */
#define SE_MAX_DESCRIPTION_LEN 64 /* MAXIMUM LAYER DESCRIPTION LENGTH */
#define SE_MAX_FEAT_CLASS_LEN 128 /* MAXIMUM FILEINFO FEATUE CLASS
DESCRIPTION LENGTH */
#define SE_MAX_COLUMN_LEN 32 /* MAXIMUM COLUMN NAME LENGTH */
#define SE_MAX_TABLE_LEN 160 /* MAXIMUM TABLE NAME LENGTH */
#define SE_MAX_SCHEMA_TABLE_LEN 30 /* MAXIMUN TABLE 'ONLY' NAME LENGTH */
#define SE_MAX_ALIAS_LEN 32 /* MAXIMUM TABLE ALIAS LENGTH */
#define SE_MAX_ENTITY_LEN 256 /* MAXIMUM ENTITY TYPE LENGTH */
#define SE_MAX_HINT_LEN 1024/* MAXIMUM DBMS HINT LENGTH */
#define SE_MAX_OWNER_LEN 32 /* MAXIMUM TABLE OWNER NAME LENGTH */
#define SE_MAX_INDEX_LEN 160 /* MAXIMUM INDEX NAME LENGTH */
#define SE_MAX_GROUP_LEN 26 /* MAXIMUM GROUP NAME LENGTH */
#define SE_MAX_COLUMNS 256 /* MAXIMUM NUMBER OF COLUMNS */
#define SE_MAX_ANNO_TEXT_LEN 255 /* MAXIMUM ANNOTATION TEXT LENGTH */
#define SE_MAX_VERSION_LEN 64 /* MAXIMUM VERSION NAME LENGTH */
#define SE_MAX_OSNAME_LEN 64 /* MAXIMUM OPERATING SYSTEM NAME LENGTH */
#define SE_MAX_OSVERSION_LEN 128 /* MAXIMUM OPERATING SYSTEM VERSION LENGTH */
#define SE_MAX_DBMSVERSION_LEN 128 /* MAXIMUM DATABASE VERSION LENGTH */
#define SE_MAX_VERSION_INPUT_LEN 62 /* MAXIMUM USER-SUPPLIED VERSION NAME
________________________________________
From: fdo-internals-bounces at lists.osgeo.org [fdo-internals-bounces at lists.osgeo.org] On Behalf Of Chris Erickson [chris at cartopac.com]
Sent: Friday, March 06, 2009 4:40 PM
To: FDO Internals Mail List
Subject: [fdo-internals] RE: ArcSDE Provider issues
Romi,
I'm talking about the string, not CLOB types. If I create a varchar(MAX) field in SDE, it maps over to an FDO string.
chris erickson
developer
chris at cartopac.com
970.493.9500 x 191
970.482.1485 (fax)
-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Romica Dascalescu
Sent: Friday, March 06, 2009 2:38 PM
To: FDO Internals Mail List
Subject: [fdo-internals] RE: ArcSDE Provider issues
Chris,
I'm not sure whay you are trying to use that function?
You should not pass the CLOB value into a string.
You must use SE_stream_get_clob, SE_stream_get_nclob with the result you should put it into an FDO CLOB.
Also you will need to create your own conversion function from byte[]/CLOB non-Unicode into byte[]/CLOB Unicode.
I would create a conversion function which converts directly from SE_NCLOB_INFO/SE_CLOB_INFO to FDO CLOB and avoid using sde_multibyte_to_wide. These functions are not designed for huge strings
Romy.
________________________________________
From: fdo-internals-bounces at lists.osgeo.org [fdo-internals-bounces at lists.osgeo.org] On Behalf Of Chris Erickson [chris at cartopac.com]
Sent: Friday, March 06, 2009 4:23 PM
To: FDO Internals Mail List
Subject: [fdo-internals] ArcSDE Provider issues
Romi,
I've been looking at the ArcSDE provider, and it handles all string conversions using the sde_multibyte_to_wide function, which allocates the Unicode string on the stack.
If I create a varchar(max)/nvarchar(max) field in sql server with sde, these show up as string fields with a length of 65,535. Allocating a 65k char array on the stack leads to access violation exceptions.
With your permission, I'd like to update these to use the heap and the multibyte_to_wide_noalloc routines, and pre-allocate the strings.
chris erickson
developer
chris at cartopac.com
970.493.9500 x 191
970.482.1485 (fax)
-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Greg Boone
Sent: Friday, March 06, 2009 1:57 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: Random question
Sure. You will have to make some arrangements with Romy or another resource to handle some of the testing.
Greg
-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Chris Erickson
Sent: Friday, March 06, 2009 3:51 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: Random question
Should I submit my arcsde fix to the sandbox then for testing?
chris erickson
developer
chris at cartopac.com
970.493.9500 x 191
970.482.1485 (fax)
-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Greg Boone
Sent: Friday, March 06, 2009 12:09 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: Random question
Please submit all your existing sandbox code submitted by Monday. At that point I will move the existing sandbox code into sandbox/3.4.0.
Greg
-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Greg Boone
Sent: Friday, March 06, 2009 1:37 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: Random question
I also like the idea of have per-feature or per-release sandboxes rather than per-user sandboxes
ie:
sandbox/3.4.0
sandbox/3.4.0_ArcSDE93
sandbox/3.3.2_Performance
Greg
-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Greg Boone
Sent: Friday, March 06, 2009 1:26 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: Random question
Typically in this case, the developer would sandbox the latest version (let's say 3.4) and the port the changes back to 3.3. I can say that right now because the code streams for 3.3 and 3.4 are very similar. However, I have not given much thought to the whole idea of sandboxing a previous development stream. Usually such changes as that are done in a sandbox in preparation of being submitted into the trunk. I can see how use can you describe can be useful, but don't think it will be a large part of whatever sandboxing occurs.
In any case, if developers want their own sandbox, I won't stand in the way. It would be easy to move the current sandbox into a subfolder.
Greg
-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Jason Birch
Sent: Friday, March 06, 2009 1:19 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: Random question
Right...
But what if someone wanted to make some relatively intrusive changes to
a provider against two different branches of FDO (say, 3.4 and 3.3) to
fix a particular defect or performance problem?
Jason
-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Greg Boone
Sent: March-06-09 10:09 AM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: Random question
I think that the only item the current setup would not support is #2,
the issue of isolation. But since we are provider driven, is there a
chance we will have multiple people sandboxing the same provider? I like
the idea of a common sandbox as it allows you to immediately determine
if the changes others are working on will work with the changes you are
making without breaking the build in the trunk, etc. Sandbox changes to
FDO itself can immediately be seen and their worth be assessed by all
provider developers.
However, this is my philosophy. If you really need a sandbox for your
own development, we could set something up.
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals
More information about the fdo-internals
mailing list