Hi folks,

I'm an Access noobie to be sure, and although it's great that most of these macros and so forth have been setup for the user I'm trying to help, the original creator is no longer available, so we're stuck crawling on all 4s basically. I have a user who is trying to run the following query to make a table, however when he does so he receives the error, "ODBC call failed. [ncr][odbc teradata rdbms] Option Parcel information is invalid. 3749"

Running a simple query to obtain the 7 rows of information this code is supposed to pull up runs fine, however when he chooses Make Table from the menu (don't remember which one, but I assume that should be fairly obvious to an Access guru... I hope. http://www.utteraccess.com/forums/images/icons/smile.gif ), it blows this error. So... it seems as though we have good access to the server/database, but I can't really find any information on the web about this particular issue and how to fix it. I've found a PDF that talks about this error and Segemented Requests, but I'm not sure if this actually pertains to our issue. Anyways, hope you can help!

Here's the code he's trying to run (when making a table):


SELECT ACCESS_VIEWS_R2_V82109_ACCESS_NAME_ADDR.BAN, ACCESS_VIEWS_R2_V82109_ACCESS_NAME_ADDR.CABS_BILL_ DATE, ACCESS_VIEWS_R2_V82109_ACCESS_NAME_ADDR.JULIAN_DAT E, ACCESS_VIEWS_R2_V82109_ACCESS_NAME_ADDR.CARRIER_RO UTE, ACCESS_VIEWS_R2_V82109_ACCESS_NAME_ADDR.BILLED_ZIP _CODE, ACCESS_VIEWS_R2_V82109_ACCESS_NAME_ADDR.BILLED_ZIP _SUFFIX, ACCESS_VIEWS_R2_V82109_ACCESS_NAME_ADDR.BILLED_NAM E_TAG, ACCESS_VIEWS_R2_V82109_ACCESS_NAME_ADDR.BILLED_NAM E_TYPE, ACCESS_VIEWS_R2_V82109_ACCESS_NAME_ADDR.BILLED_CIT Y_STATE_ZIP, ACCESS_VIEWS_R2_V82109_ACCESS_NAME_ADDR.CPNI_IND, ACCESS_VIEWS_R2_V82109_ACCESS_NAME_ADDR.BILL_NAME_ ADDRESS_1, ACCESS_VIEWS_R2_V82109_ACCESS_NAME_ADDR.BILL_NAME_ ADDRESS_2, ACCESS_VIEWS_R2_V82109_ACCESS_NAME_ADDR.BILL_NAME_ ADDRESS_3, ACCESS_VIEWS_R2_V82109_ACCESS_NAME_ADDR.BILL_NAME_ ADDRESS_4, ACCESS_VIEWS_R2_V82109_ACCESS_NAME_ADDR.BILL_NAME_ ADDRESS_5, ACCESS_VIEWS_R2_V82109_ACCESS_NAME_ADDR.BILLED_NAM E, ACCESS_VIEWS_R2_V82109_ACCESS_NAME_ADDR.BILLED_ADD RESS, ACCESS_VIEWS_R2_V82109_ACCESS_NAME_ADDR.CUSTOMER_N AME, ACCESS_VIEWS_R2_V82109_ACCESS_NAME_ADDR.ACNA, ACCESS_VIEWS_R2_V82109_ACCESS_NAME_ADDR.ALT_EXCHAN GE_COMPANY_NAME, ACCESS_VIEWS_R2_V82109_ACCESS_NAME_ADDR.CUSTOMER_I ND, ACCESS_VIEWS_R2_V82109_ACCESS_NAME_ADDR.FINANCIAL_ DATA_MONTH INTO SWBTTESTa
FROM ACCESS_VIEWS_R2_V82109_ACCESS_NAME_ADDR
WHERE (((ACCESS_VIEWS_R2_V82109_ACCESS_NAME_ADDR.BAN)="6100724017966"));


Thanks in advance! This code was apparently working until about a week ago, so not really sure why it all of a sudden took a dump. If I can provide any relevant clues I'll be more than happy to.

Thanks in advance!

Sean

You cannot do a SELECT INTO it must be an INSERT INTO

also do you have write access to SWBTTESTa? Does it actually exist in your schema?

David

Hrm okay, I'll change that and see if it does anything! SWBTTESTa was just a table name he randomly picked (just put an "a" at the end of the file name when prompted to create a file name), so I assume he does? I'm not really sure where the database is creating the table exactly so I can't really check the permissions offhand, but if you point me in the right direction I probably can.

Any idea why this macro would have worked for months and then all of a sudden stop? Nothing has changed, so it seems that the SELECT INTO line would have worked at one point, however like I said I'll change it and see what happens... just doesn't make sense.

Thanks!

I stand corrected you can use Select Into if the table you are using a make table query when the destination table does/not exist in a different mdb.


SELECT ID, fld1, fld2, fld3, ID INTO [Table 2] IN 'C:\Test\db1.mdb'
FROM Table1
WHERE (((ID)=1));

this is the syntax access derived

David

Any idea why this macro would have worked for months and then all of a sudden stop? Nothing has changed, so it seems that the SELECT INTO line would have worked at one point, however like I said I'll change it and see what happens... just doesn't make sense.

Thanks!
How do you know nothing has changed? Have you checked this? People sometimes corrupt the SQL source and think they have corrected it. - ie deleted INSERT and corrected it with SELECT. Users never admit to things like this so we will never know.

SELECT INTO can never work.

How do you know nothing has changed? Have you checked this? People sometimes corrupt the SQL source and think they have corrected it. - ie deleted INSERT and corrected it with SELECT. Users never admit to things like this so we will never know.

SELECT INTO can never work.


This seems to be differing from what the previous poster has said... so now I'm confused.

And these macros are created by other people and then sent out for use throughout the company. The user is the admin of this database however, so no one else has the ability to change it except for him. He kinda wants this to be fixed... and would have answered me honestly when I asked if anything had been changed. I'm not a conspiracy theorist, so I don't see any possible reason as to why he would lie about that. After doing IT for the last 6 years, I know users lie, but generally not quite like this. Finding another user with the same macro in their database might be a pain, considering we're talking about probably well over a hundred thousand employees with no easy way (that I can see) to check on who uses what macro. Unless each macro contains some sort of creator signature or something, I also don't see how I can easily find out who made the macro. :( Any way I can easily do any of that? Please remember that I'm an Access n00b and no next to nothing about SQL/Teradata database administration.

But as I said, I will change it and see what happens, and then get back to you!

Thanks much.

This seems to be differing from what the previous poster has said... so now I'm confused.

Sorry I didn't see David's post so I have learnt something. There do seem to be circumstances when it will work.

No worries. The user will hopefully be trying anyways. We're also going to reinstall the ODBC drivers just for gits and shiggles, as well as try to reboot the server if I can figure out which one this database is located on.

Welp, the user finally got back to me and we reinstalled the ODBC drivers since we were having issues getting the server reset... and it worked! I'm clueless as to what part of the drivers got changed/corrupted, but we have pre-configured packages from out IT department that install them for us, so it was pretty easy in the end... I wasn't sure how that worked with this company, so I was hesitant to try that at first, but oh well. Now I know!

Anyways, thanks for all of your suggestions. Hopefully this helps someone else out.

Have a happy New Years!