[fdo-internals] RE: ArcSDE Provider issues

[Romica Dascalescu]

Make the changes and we will at review if is ok or not.

Romi.
________________________________________
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