Hi,

I have written an application which takes *.txt files and uses them as imports to tables on my Server.

IMPORT TABLE "Activity" FROM "Activity.txt"
IN STORE "TmpUpdate"
FORMAT DELIMITED
ENCODING AUTO
DELIMITER CHAR '|'
QUOTE CHAR #0
MAX ROWS -1

When I run this on my client machine with a Remote Session I receive the following error:
ElevateDB Error #9999 Access violation at address 000000000082E409 in module 'edbsrvr.exe'. Read of address 0000000000000000

I have tried this in DB Manager on the client machine but get the same result.

All of the files are in the STORE and the Activity table exists in the database.

If I take the exact same statement and run it on a copy of DB Manager on the Server itself it runs fine!

Any thoughts would be welcome.
Nigel

Nigel


First things to check:

1. Are you running the same version of EDBManager on both the client & the server machines?
2. Are you sure that from the client machine you are pointing to the same data as the the server does?



Roy Lambert

Hi Roy, thanks for the reply.

Yes running the same DB Manager on both, although I only used DB Manager to test that the problem wasn't in my code.

In the application I use the same remote session to create the DATABASE, TABLES, INDEXES and STORE on the remote server. I also use COPY FILE to take the files from a local STORE and put the in to the server STORE.

So I am fairly sure that the remote session works ok.

All this works fine until with the same remote session I try to IMPORT the "Activity" table, which is when the error appears.

Which is why I tried to run it from DB Manager, but got the same error when running it from the client, but no error when running it from the server.
Nigel

>>Roy Lambert wrote:

Nigel


First things to check:

1. Are you running the same version of EDBManager on both the client & the server machines?
2. Are you sure that from the client machine you are pointing to the same data as the the server does?



Roy Lambert<<
Nigel

Hi,
One further update to this,

I have just removed the line:

QUOTE CHAR #0
from the IMPORT statement and re-ran it and it worked fine.

So I guess the question is why doesn't it run on a remote server with the QUOTE CHAR #0 in it?



>>Nigel wrote:

Hi,

I have written an application which takes *.txt files and uses them as imports to tables on my Server.

IMPORT TABLE "Activity" FROM "Activity.txt"
IN STORE "TmpUpdate"
FORMAT DELIMITED
ENCODING AUTO
DELIMITER CHAR '|'
QUOTE CHAR #0
MAX ROWS -1

When I run this on my client machine with a Remote Session I receive the following error:
ElevateDB Error #9999 Access violation at address 000000000082E409 in module 'edbsrvr.exe'. Read of address 0000000000000000

I have tried this in DB Manager on the client machine but get the same result.

All of the files are in the STORE and the Activity table exists in the database.

If I take the exact same statement and run it on a copy of DB Manager on the Server itself it runs fine!

Any thoughts would be welcome.
Nigel
Nigel

Nigel

This is the part of the map that says "here be dragons"


What makes me thing it could be different data is that you're using the delimited format for the import and

<<If the QUOTE CHAR clause is not included, then the default quote character for character strings is the double quote '"' character.>>

That suggests that there are character fields, and from (I hate to use it but its the first I found) wikipedia

<<Fields containing a line-break, double-quote, and/or commas should be quoted. (If they are not, the file will likely be impossible to process correctly).>>

that they need quoting which is ok when you take out QUOTE CHAR #0 since ElevateDB will be using double quote

This also prompts me to ask are both imports defined as ansi or unicode? If ansi I'm not sure at all how it would process #0.

I'm guessing that the txt files are outside of your control. If not I suggest a change to XML for import. I used to use csv, had a problem (which has since been fixed) and made the switch to xml. I found it a) more robust, and b) faster.

The only other comment I have is that if the same piece of software operates differently on the same data on two different machines then it has to be something different on the machines. Language, OS or something weird.

Roy Lambert

Thanks Roy,

As you say the text files are out of my control.

Although the test that I am using is a delimited file that contains no other quotation, commas or anything apart from A-Z ascii characters.

I have also tried replacing the QUOTE CHAR #0 with QUOTE CHAR #34
or any other CHAR apart from #0 and they work.

Also this only happens when runnig the IMPORT on a remote session.

I have logged it in as an incident as I can't think whey there should be a reason why #0 is excluded when usin it remotely.





>>Roy Lambert wrote:

Nigel

This is the part of the map that says "here be dragons"


What makes me thing it could be different data is that you're using the delimited format for the import and

<<If the QUOTE CHAR clause is not included, then the default quote character for character strings is the double quote '"' character.>>

That suggests that there are character fields, and from (I hate to use it but its the first I found) wikipedia

<<Fields containing a line-break, double-quote, and/or commas should be quoted. (If they are not, the file will likely be impossible to process correctly).>>

that they need quoting which is ok when you take out QUOTE CHAR #0 since ElevateDB will be using double quote

This also prompts me to ask are both imports defined as ansi or unicode? If ansi I'm not sure at all how it would process #0.

I'm guessing that the txt files are outside of your control. If not I suggest a change to XML for import. I used to use csv, had a problem (which has since been fixed) and made the switch to xml. I found it a) more robust, and b) faster.

The only other comment I have is that if the same piece of software operates differently on the same data on two different machines then it has to be something different on the machines. Language, OS or something weird.

Roy Lambert
Nigel

Nigel


Just out of interest what happens if you go the other way round? ie swap the client & server role for the two PCs

Roy Lambert

Roy,

Funny you should say that, I was just finishing off the exact same test.

And yes the problem still occurs with QUOTE #0 no matter which way around I do it!


>>Roy Lambert wrote:

Nigel


Just out of interest what happens if you go the other way round? ie swap the client & server role for the two PCs

Roy Lambert<<
Nigel

Nigel


Great minds etc

Its seems as though its in the comms layer. A final test would be to create the tables on the client machine and try the import and see what happens there.

Roy Lambert

Roy,

I already do that, this is part of an update process I have written.
If the user is running a local database the Database, Tables, Indexes and Store are created locally and the Import Table process runs just fine.

It only becomes a problem when the user opts to update a replica database on a server using exactly the same code but through a server session.
Nigel