Case

2: If you are running everything local then you local DSN pointing to the dbf directory will do it.

Are you usng case

1 or case

2 ? I suggest that you get the ALL local solution going first. It sounded like you are using a local DSN pointing to a Network directory on a separate Server box. I`ve never try that before and I`ll do some experiement. Also, give some details in your ODBC setup will help.

Frank

On 9/18/98 6:57:10 PM, Art wrote: \> Greetings All,

All went well with the DLL registered locally & PWS and \> then...

I published the page to my NT4/IIS4/MTS web server. Here`s the \> setup: 1. DLL in the same folder as the Web (the Eval DLL) 2. DLL is \> registered in MTS & appears OK 3. File DSN is on a separate server 4. \> dBase IV DBF is on the same server as the DSN

Now it returns the \> following error:

Microsoft OLE DB Provider for ODBC Drivers error \> `80004005`

[Microsoft][ODBC Driver Manager] General error: Unable to \> create file buffer ---- I tracked the process on my local \> machine and it uses the WindowsTemp directory to create the buffer. I was \> wondering if there was a way to specify the TEMP path for the buffer \> creation so I don`t have to mess with permissions of system folders. --TIA

• ODBC Buffer Error (reply)

  On 9/19/98 10:09:40 AM, Frank wrote: \> Art, Need a bit clarification. [snip] Hi Frank, Here`s the skinny... Scenario 1 (Everything works fine when everything but the data & DSN are local): 1. Win95 client (OSR2)using IE4(SP1) 2. PWS4.0 running on the client 3. the DLL regsvr32`d locally on the client 4. the file DSN is located in a subfolder of the data folder (i.e. \FileServerMyDataDatasrcMyDSN.dsn) pointing to the folder (\FileServerMyData) containing the two (2) dbf`s that are used (on the file server 5. the dBase IV (actually Clipper dbf`s) dbf`s are on the file server (\FileServerMyDataTable1.dbf & \FileServerMyDataTable2.dbf)and have no memos or BLOB`s 6. ASP`s on client hitting PWS running on client (http://Win95PWS/MyWeb/ASPdbTest.asp) Scenario 2 (When I attempt to publish the same stuff on our intranet): 1. Same client (PWS stopped & DLL un-regsvr32`d) 2. Same DSN & data (System DSN works fine, but then the admin "pains" increase... so call me lazy, I`m a programmer--lazy is my credo!) 3. IIS4 running on webserver (\WebServer) under NT4 4. ASP moved to webserver (\WebServerMyWebASPdbTest.asp or http://TestSvr/MyWeb/ASPdbTest.asp) 5. DLL registered in MTS2.0 running on the webserver. --under these circumstances the buffer error is generated. The crux of the issue seems to be permissions on the folder in which the buffer is being created (when using a file DSN). The problem is determining which folder it is (in Scenario 1 it is c:windows emp). The solution would be to specify the `TEMP` folder. Things around here change--OFTEN. I was hoping to have a single point of administration (one File DSN) for the access to this data. That way I can just pop open NotePad and modify the DSN as desired obviating the need to modify system DSN`s on each of the servers involved. I realize this has nothing to do with ASPdb per se. I just hoped that someone had run into this before & had resolved it. This is my first time posting in this forum so I apologize if I am not utilize this tool correctly. Please let me know if there is a better location/topic/tags etc. that I can use to better align myself with forum expectations. Here is my setup; I am attempting to use the DB Tools suite in LabView (LabView 16.0 (32-bit)) to create (Open Connection) a database connection reference object and then use the Select Data tool to query my PostGRE server for the required information. Pretty standard stuff I imagine. I'm using the string variation of the Open Connection tools with a network filepath leading to a stored dsn file containing all the network information. I then feed my username/password info and timeout information into the sub-vi. On other machines around my workplace that have a similar program (I'm duplicating portions of it for another project) run this portion of the program fine. However my current setup on my own dev PC receives an error on the Open Connection tool. I'll include screenshots of the vi and the error. I've searched NI forums, I've searched forums specific to ODBC and the very few posts even contain this error suggests one of three things: The first possible issue that the forums suggested was that the dsn file and dsn object in the ODBC Data sources manager tool was configured with the 64 bit version of ODBC and needed to be deleted and reconfigured using 32 bit. The second suggestion was that whatever is running the driver for this connection does not have either the space or necessary permission to create the temporary files it needs to run this process. The solution for this suggestion was to ensure the operating account has the needed permissions and that the temp directory is not full, or (as part of the suggestion mentioned) renaming one temp file to CTT0 as apparently ODBC cycles through CTT#### file names and if it reaches CTTFFFF without being able to cycle back to 1 it can cause an error. Lastly one forum solution was that the program running the task utilizing the ODBC driver does not have enough handlers and to manually allocate more using the SetHandleCount function from the Windows API to allocate more to this task. I've completed the first task without the problem being fixed. I am unaware of whether or not LabView utilizes a separate temp folder than most other programs, or if LabView isn't even involved but rather I need to find the ODBC temp folder. Either way I did search the usual places (i.e. /Temp and AppData/Local/Temp and Tmp) and neither had any temp files with the naming convention mentioned above. In fact I did an entire C drive search for all tmp files and none of them matched that naming convention. So I'm not sure if that is the problem. I'm not familiar enough with the third solution to be sure how to even tackle it or if I'd be wasting my time pursuing it as it may be unrelated and I simply am not aware. I also understand that this could be unrelated to LabView as a whole and I might need to relocate to the Microsoft ODBC forums for further assistance. But on the off chance that someone here has ran into this problem within LabView specifically I figured it was worth a shot to reach out. Please ask any questions if I need to elaborate on any portion of this post and I appreciate any feedback anyone can offer.