Hi

Is there any way i can increase the amount of columns in a table before importing data? I am importing data from a notepad doc that needs abt 300 columns but i can only get abt 100 columns.

Thanks for any help

There is an absolute maximum of 255 fields in a table, sometimes other constraints make this difficult to achieve. Can you split the data into groups and use multiple tables?

Even if you can do this, your data is very unlikely to be normalised. Tables should be narrow and long not wide and short.

Thanks

Do you know how i go about adding these fields on? Can i make it as a default value of fields before i import data into it? ie: every time i import data, it needs to fill all 255 fields.

Sorry, I don't understand your question. If your text file has more than 255 fields you can't import it into a table with 255 fields unless you skip the extra fields.

Hi

When i am importing data, i can only import upto 100 fields and not 255. Is there a way to import data in all 255 fields?

Hi

What you have not indicated is whether the notepad file is comma delimited of proportionally spaced. This makes a difference.

If it is the later then you can write code to loop across each row in the text file and extract mid strings to add to specific fields in your table. If not then it becomes harder. Make sure the font in your text file is also proportionally spaced this will enable you to decifer the ordinal position of each entity.

Code Master:cool:

The text in notepad is seperated by the pipe symbol - |. when i import data, i use the delimited option with 1st row beign the column headings. I do not have much knowledge of coding so am not sure how to do looping.

Thanks

The problem is that Access WILL NOT do more than 255 fields in a given table.

The next comment will sound a bit arrogant, but it is not intended that way. There is NO WAY that your 300-column spreadsheet is properly normalized. And if it is, then you shouldn't be using Access anyway. So the FIRST issue is really one of designing how things should appear.

I think you would get greater benefit if you gave us SOME details about what is in that spreadsheet. SOME details - but not every little detail. Give us an overview of the problem you are addressing by building a database, not the problem you are having while trying to build that database. (We already know the latter problem.)

To give them the benefit of the doubt, maybe they're trying to import a flatfile of data that was previously entered into something like excel, and then plan to use code, action queries etc to populate a properly normalized relational design.

Maybe?