A trappable error (E06D7363) occurred in an external object. The script cannot continue running.

I receive this error when reading and writing data concurrently from two Internet explorer windows from an asp page. When using one browser window the error doesn't occur. The error occurs only when there are two browsers creating connections at the same time.  

Does the qbcust.asp script example found within the forum topic:  How can I see QuickBooks data in a Internet Explorer Browser using Windows XP?  run on multiple browsers on your computer?

What browser, IIS revision and Windows O/S are you using?

Environment to reproduce the error: Server 2003 , iis 6.0, qb pro 2006, remote connector, qb version 7.0

When running and refreshing qbcust.asp from two or more browsers (IE 6.0) located on different machines I receive the following error message:

QODBC Customer Web List Demo Page
Preparing to Create Connection Object
ADO Connection Created
ADO Recordset Created - Opening QuickBooks Sample Company File

Provider error '8000ffff'

Catastrophic failure

/Test/qbcust.asp, line 27

---------------------end out put--------------------------------------------------------

QODBC Customer Web List Demo Page
Preparing to Create Connection Object
ADO Connection Created
ADO Recordset Created - Opening QuickBooks Sample Company File
QODBC DSN QuickBooks Data Open
ADO Recordset Open

Customer - Outstanding Balance
*****************************
Adam's Candy Shop - $40

Active Server Pages error 'ASP 0115'

Unexpected error

/Test/qbcust.asp

A trappable error (E06D7363) occurred in an external object. The script cannot continue running.

---------------------------------end output-----------------------------------------------

The above two errors do not happen everytime, but about 30% of the time one of the two browsers will crash with either one of the above error messages. The error typically doesn't occur when running from two browsers from web server. However when running and refreshing two browsers on different machines the error is easily reproduced. I checked the qodbc message log but did not find any logs that corresponded to the time of the failure.

Please advise.

The directory security tab in iis shows my virtual directory as having the following settings:

Enable Anonymous acess = checked

User: IUSER_Server1

Integrated Windows Authentication = checked

------------qodbc settings-----

use Optimizer  = unchecked

Those are the settings that you mentioned. Should I change any of them?

Can you test on your side to see if you can reproduce the error? Take the qbcust.asp file and wrap the code section in a while loop. Do about 10 iterations. Run a single browser and the script will print out 10 times. Run another browser from another machine and then refresh the first browser so that they are both running at the same time.

Note: You cannot do this test with two browsers on the same machine because they will run sequentialy instead of in parallel. The first browser will hold up the other browser from execution until it finishes and then the second browser will resume execution.  Therefore they are not running concurrently and that is the root of the problem.

I have tried the DCOM Server method to eliminate the trappable error problem. It has not yet worked. The qbcust.asp file runs fine if only using one browser, but if two browsers are used on different machines it will crash if making the request at the same time. To make the problem more pronounced I have modified the qbcust.asp file to include a loop around the page. I would expect the DCOM Web Server Edition of QODBC to have the ability to concurrently serve quick books data to at least two clients simultaneously.

Here is a copy of the script with the html portion excluded:

dim i

i = 0

while(i < 10)

 Dim oConnection

Dim oRecordset

response.write "Preparing to Create Connection Object" & vbCrLf

response.flush

Set oConnection = CreateObject("ADODB.Connection")

 response.write "ADO Connection Created" & vbCrLf

 response.flush

Set oRecordset = CreateObject("ADODB.Recordset")

response.write "ADO Recordset Created - Opening QuickBooks Sample Company File" & vbCrLf

response.flush

oConnection.Open "QuickBooks Data"

response.write "QODBC DSN QuickBooks Data Open" & vbCrLf

response.flush

'oRecordset.CursorLocation = adUseClient

oRecordset.Open "SELECT * FROM Customer" , oConnection', adOpenStatic, adLockOptimistic

response.write "ADO Recordset Open" & vbCrLf

Response.Write "" & vbCrLF response.flush Response.Write "Customer - Outstanding Balance"&"" & vbCrLF

Response.Write "*****************************" & "
" & vbCrLF

Do While (not oRecordset.EOF)

 Response.Write oRecordSet.Fields("Name") & " - $"

 Response.Write oRecordSet.Fields("Balance") & "

oRecordset.MoveNext Loop

Response.Write "*****************************" & "

" & vbCrLF

oRecordset.Close

set oRecordset = Nothing

oConnection.Close

set oConnection = Nothing

i = i + 1

 wend

Yes, my repeat loop is opening and closing the connection. That was done on purpose to test concurrent connections. Imagine this scenario: I have a web site with 10 users accessing quick books data. Each one of them is looking at qbcust.asp. QBCust.asp has one connection per page. All ten users fresh the screen simulataneously or very close to simulataneously. That means that there will be ten concurrent connections. Putting a loop around the creation and closing of a connection is a reasonable way to stress test qodbc and concurrency issues when the same page is run from two or more browsers.

You suggested having one connection per page. I tried that preveously with the same results. The problem is concurrent access not opening and closing connections on a page. Keep in mind that the qbcust.asp file works fine in a loop when executing with from only one browser. That implies that creating and closing connections is not responsible for the errors. I would however agree that creating and closing connections is not the most effiecient use of the quick books resources, but the point is to test concurrency not write efficient web page.

Are the workstations logging into your server, or can they access the webpage (test script) without logging into the server?

Actually I have a idea, I believe you are getting invalid cursor states because both test scripts are using the same table, could you run a "SELECT * FROM Customer" loop in one workstation browser session and "SELECT * FROM Vendor" loop on the other and let me know what happens?

Ok, I modified the file to "select * from Invoice" and pulled the txnid and txnNUmber in the record set. I used the Invoice table because it has more records in it than the Vendor table when using the sample company file.

I ran the qbcust.asp file from the client machine and a qbinvoice.asp from the server. Using a different table did not fix the problem. The qbinvoice.asp script runs perfectly when executing alone and crashes when running the qbcust.asp script from another machine at the same time.

I don't understand what your are refering to when you ask if the work stations are logging into my server. When I run the testDCOM.asp the auth_user is = "" (empty string). This does not populate unless anoymous authentication is unchecked, however unchecking that options causes the widows authentication challege to prompt the user for windows credentials, which is not desired. The testDCOM.asp script return successful for all components.

Microsoft says:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dniis/html/windebug.asp

(look about halfway through the article)

ASP 0115—Access Violation

Access violations are primarily due to heap and stack corruption.

Access violations occur if you do something like allocating a block of memory and trying to read/write beyond that block.

--------------------------------------------------------

Ok, last test. Switch the QODBC optimization back on, run queries on both the customer and invoice tables in VB Demo to update the optimized tables and then modify your test loops to do:

"SELECT * FROM Customer NOSYNC" and "SELECT * FROM Invoice NOSYNC"

This will bypass calling the data from QuickBooks and let me know your findings.

I have switched the optimizer back on. Ran select * from Invoice and Customer. Then modified the qbcust.asp and qbinvoice.asp to contain the "NOSYNC" tag in the select * from [tablename] NOSYNC.

Here are the results: The qbcust.asp page runs fine just like normal. I get all the customers and their balances 10 times in a row. However the qbinvoice.asp page opens and closes the connection 10 times but there are no records in the result set. I'm not sure if that was the desired behavior or not. The qbcust.asp and qbinvoice.asp do not crash or give me the trappable error problem, however there are no results in the invoice record set. I'm clueless as to why the invoice record set has no rows in it but the customer recordset does have rows.

If I remove the optimizer option and remove the nosync from the qbcust.asp and qbinvoice.asp then the invoice result set goes back to normal, but I receive the trappable error when running two browsers concurrently. I'm not sure what the optimizer and the nosync are doing so I don't know what to make of the results.

Maybe the problem is related to iterator that loops through the recordset.  The problem does not appear to be related to the connection because the connection opens and closes 10 times in a row rapidly(less than a second with no result set.), while the qbcust.asp page is retrieving results. The problem only occurs when reading records sets from two tables concurrently. Sometime I will receive EOF execeptions and MoveNext exceptions, other times I get the trappable erorr execption and lastly I sometimes get a provider error. I get all these errors randomly and cannot predict which error will occur next but they are all related to reading two concurrent record sets at the same time.

Please advise as to the next course of action. 

Thanks for the details, it confirms my testing. Basically you must use the QODBC optimizer and the NOSYNC tag in all your table queries within your .asp web pages . To fully resync a table you do:

sp_optimizefullsync Invoice

and then you can update it manually at any point of time later on, when you want, by doing:-

sp_optimizeupdatesync Invoice

Once you have resynced your Invoice table, you will get results in the qbinvoice.asp NOSYNC loop. The NOSYNC tag basically says, check with QuickBooks security that you are allowed to read the table and then pass through the query to the SQLite back end (the QODBC Optimizer). This works in multi-user mode, however when you pass a XML request to QuickBooks and pass another from a second user (or ID) while the first result XML stream set is being returned we get invalid cursor errors that are most likely causing your access violations.  

I can also reproduce the same error by running two VB Demo instances on my desktop, so I need to have a talk with our Software Engineer and the President of FLEXquaters.com LLC on what we are going to do to address this situation. In the meantime you should use the NOSYNC tag option.

For more information on the QODBC optimizer see: How do I setup the QODBC Optimizer? Where are the Optimizer options? 

I have run sp_optimizefullsync Invoice and sp_optimizeupdatesync Invoice. Then attempted to run "Select * from Invoice NOSYNC" from the qbinvoice.asp, however this query did not return any results. I ran the same select statement from vb demo and received a result set back. Why does the vb demo return resutls and the asp page does not? Turning off the optimizer or using Unoptimized or CallDirect tag returns records from the Invoice table, however the concurrency issue is still present when running from two browsers. How can I use "Select * from Invoice NOSYNC" from an asp page and receive results?

I ran the sp_optimzefullsync invoice from an asp page, then ran the qbinvoice.asp. I am still not receiving results. I also tried "Select * from Invoice verify", which takes longer but still doesn't produce a result set. Do you have any other suggestions to make "Select * from Invoice NOSYNC"  work?

The directory security tab in IIS manager is running under local Administrator (test purposes), so there should not be a permissions problem.  I checked the opt file in the documents and settings of the Administrator and the modified date shows as todays date. I believe that its being updated. I don't know what else to check, please suggest something.

Is it possible that we might escalate this issue to include some phone support and a walk through in order to get this working properly. I am attempting to produce a product and need to resolve this issue as soon as possible. I DO NOT have a product unless I can get qodbc to work with a web server concurrently. This is essential.

Sometimes SELECT * fails, so try something more along the lines of:

Select TOP 10 TxnId, RefNumber, CustomerRefFullName from Invoice order by TIMECREATED desc

and also try other tables, other than Invoice or InvoiceLine for now, and let me know how the queries of the other tables go.

I have tried select top 10 TnxId, TxnNumber from Invoice NOSYNC with no result set. I also tried "select top 10 tnxId, txnNumber from invoiceLine NOSYNC" with no sucess. However "Select * from Customer NOSYNC" returns results.

 I don't really care if the "NOSYNC" syntax returns results. What I care about is if the no sync syntax fixes the concurrency issue. Since "Select * from Customer NOSYNC" returns results, I ran the script from two browsers and still received the access violation error. The "NOSYNC" keyword is not a fix for concurrency and therefore neither is the optimizer. It does seem as if the optimzer has some bugs in it though.

I reinstalled server 2003 on a differnt machine and setup everything again from scratch. Guess what no trappable error during concurrent usage. I came accross this post on your web server information page:

Several of our customers who had trouble getting the Web Server Edition to run without errors, were able to get it running perfectly well after reinstalling Windows from scratch on the box. Perhaps there were some corrupt system files that prevented proper operation, but if all else fails, try another machine or new OS load.

While I'm glad that I have gotten the program to work, it is simply not possible to ask our customers to reinstall server 2003 in order to get qodbc to work.

Based on the test that I have done, I believe that the problem is IIS 6.0. Here is what I did to come to that conclusion. First I got the new server working perfectly with a local qb file and qodbc dcom server. Then I pointed qodbc on the server that doesn't work at the remote connector on the server that does work. This means that I'm using IIS 6.0 on the good server  to to server qb data from the server machine that doesn't work. This scenario works perfectly. To make the test complete I reversed the test. I pointed the qodbc on the bad server to the remote connector on the good server. I then attempted to run qbcust.asp from IIS 6.0 on the bad server but connecting to data on the good install. In this scenario current access fails with the trappable error. This leads me to conclude that IIS 6.0 on the bad server has some settings or configuration that are different than the IIS 6.0 on the good server.

I have yet to issolate the IIS 6.0 settings that allow one server to work perfectly and the other to crash. I am speculating that maybe by reinstalling iis 6.0 on the bad server will fix the problem. However I cannot reinstall IIS 6.0 on the bad server because the server is in use and has many web site, application extensions, asp1.1 and asp2.0 installed.

Do you have suggestions as to how I can determine what settings or configuration is causing the problem? Have your developers been able to determine the cause of the problem?

I also handle callback support and basically I can have QODBC running on a web server over the phone within 20 minutes providing that IIS is installed (some servers didn't even have IIS installed) and nothing has been done to alter it from the OS standard install. Other developers have failed to get a server going but rebuilt the server and everything worked fine. I once had a developer with three servers all the same that could get two servers going with QODBC but not the last one. They were the same hardware, same OS and all setup the same except for IP and Server Name (of course). Because it was a new server, he wiped the disk, reinstalled the OS like he did three times already and it worked.

Most problems in deployed servers arise because of some corruption by either an extension being applied, a virus (or anti-virus program setting) or even an IP/port attack on the server, that currupts a registry setting or part of the OS. All of which is a little beyond the scope of this humble forum. Unfortunately I don't tend to hear how problems are finally resolved and all outcomes, but I have to say more developers are sharing their experiences, like you, and we all learn and gain valuable knowledge in the process.

If I come across something further, I will add it to this thread.

Do you think that you could resolve my concurrency issue if we pay for call back support? What happens if you can't solve the problem, ie qodbc access fails when accessed concurrently? Do we still have to pay? If you think you can solve the concurrency problem then I belive that we are ready to pay for call back support. 

 Our company has invested 3 months of work developing a web based product using qodbc. It seems strange that there is such a large bug in a product that advertises it self as web server capable. How can you advertise a product as web server capable if it doesn't support concurrency? I do not think that I am doing anything out of the ordinary. How have all of your other clients gotten around this issue? Have your other clients ever had this issue?

What can we do to resolve the situation? I would like to get on the phone with someone with techinical knowledge of how to trouble shoot this issue. If I must pay for support then I will do so but only relucantantly because I feel that the unless qodbc can run concurrently on a web server, then  it is not installed or configured correctly. I have already installed IIS and the Operating system. I am not asking for your techinical support on anything other than getting qodbc installed and working perfectly on  a web server. By working perfectly I mean it must be able to run concurrently. I believe this is a reasonable request for installation support. How can you say that qodbc is installed successfully if it crashes when used concurrently? I jus don't understand?

 Its been so hard to get support. For example, you web site says

"Those purchasing the product will receive Free Installation Support for 30 days from date of purchase. Program anomalies will be addressed at no charge and updaters posted on our web site. Support issues specific to your application or requirements may be subject to a $30 per incident consulting fee."

How can I get the free support mentioned above? Please give me a phone number or a link to the web site where I do not have to purchase this free support. If you direct me to the following site : http://www.qsupport.com.au/index.html?lang=en-us&target=d1.html Please provide instructions on how to receive the free installation support that is advertised.

Thank you

Simply call the sales office from where you purchased QODBC with the purchase details and date:

USA: FLEXquarters.com LLC on: 800-932-6448 or +1 248-360-7842
Asia Pacific: Data Access Worldwide on: (03) 9761 3644 or +61 3 9761 3644
UK: Architectronic Ltd on: 0845 638 3730 or +44 (0)845 638 3730

As you have already advised, you have already reinstalled server 2003 on a different machine and setup QODBC again from scratch without any trappable errors during concurrent usage. This being the case, leads us to believe that you have an enivironmental issue with your client's server and not QODBC. We provide QODBC support only. Our support scope is to provide the necessary information to you to be able to install and configure QODBC to be used by a web server. The actual configuration, setup and fault correcting of a web server isn't something we do.

There also has been no response thus far from the QODBC Software Engineer on either this issue or the other concurrrecy issues raised in our Tier/Level 2 support system.