General

Re: Getting at the schema --- revisited

jonbrave — Wed, 24 Nov 2004 09:26:47 GMT

Thanks. I think I get the drift. Quite tricky, then...

For now, I think I'll keep this for reference. I'll "hard code" into IP script knowledge of the tables/columns which hold datetimes which need converting between UTC & local time. This is, in effect, what I have had to do when exporting to reporting tools anyhow (i.e. everywhere in the report that I drag in a datetime field I'm responsible there for calling an output-converting display function somehow in the report tool) --- I wasn't generic there, so I suppose I don't have to be in IP, for now.

Why do I seem to be the only developer haunted by UTC/localtime issues all over the place...?

Re: Getting at the schema --- revisited

Greg Collins — Wed, 24 Nov 2004 00:21:23 GMT

First off, schemas get broken up by InfoPath when there are mixed namespaces. It separates each namespace into its own schema file and then uses the import statement to combine them all back together at runtime.

If the schema you want is part of your main schema then you are okay. If it isn't then you have the problem that whenever you update your datasource, the schema files are recreated with new names. This is where things are more tricky.

If the latter is the case you should be able to read into the manifest file, find the data connection in question and read which .xsd file it uses, and then use that info to load the file.

Now... the import stuff... You should load the main .xsd file, and if it doesn't have what you want, load the first import .xsd file. If it doesn't have what you want, load the second, and so on.

Unless you *KNOW* which .xsd file you need, I would recommend doing this in a procedural way. The Import statements tell you the name of the other .xsd files, which you can then load.

Let me know if this helps, and if so, what route you chose.

Greg Collins [InfoPath MVP]

Getting at the schema --- revisited

jonbrave — Tue, 23 Nov 2004 18:40:20 GMT

I asked elsewhere about getting at the schema at run-time. Greg answered:

quote:
You cannot directly access the live schema. You can however load the schema for reference purposes. You will be working with a local copy of the schema and so any changes you make will not be affecting your form... but this is a good thing as changing your schema live would likely have disasterous results.

Here's the code to get access to you schema file. One you have it loaded you can access it just as you would any other DOM.

oMySchema = new ActiveXObject("msxml2.DOMDocument.3.0");
oMySchema.async = false;
oMySchema.load("mySchema.xsd");

I am now revisiting this. I am fine with the principle of the answer. But I have two questions:

1. My db does datetimes in UTC. I want IP to convert to/from localtime on output/input. I plan to do this by converting all datetimes when queried and back when submitted. (I don't really want to discuss this bit --- I think I know what I need to do.) I think this seems doable in principle? So I need to identify all datetimes at runtime. I do not think this can be done from the info in the DOM?

2. So I need to *read* the schema; then I can figure it. But, I don't understand all the XSDs involved. For example, loading my "mySchema.xsd" (as per suggestion) does not seem enough: it has stuff in it like:

<xsd:import schemaLocation="schema3.xsd" namespace="http://www.tempuri.org/DataSetIC.xsd"/>

Loading "mySchema.xsd" does not seem to "do" the "import"? If I load "schema3.xsd" I seem to get what I want. But how do I know which file this will be (I keep developing)? I want the schema for "DataSetIC"; what's a robust way to identify the file or get that schema (e.g. can I force the "import" to happen from "mySchema.xsd")?

I know this is tricky, but I don't see any alternative...